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Section  1 


INTRODUCTION 


1.1  Identification 

This  document  is  a  Technical  Repon  •  Study/Services,  Contract  Data  Requirement  List  (CIXtL)  data  item 
A003  for  the  Simulator  Networking  niase  I SBIR  Project,  contraa  number  N61339'92-C-0036. 

Amherst  Systems  is  working  to  add  Distributed  Interactive  Simulation  (DIS)  capability  to  the  Integrated 
Test  Bed  (TTB)  facility  aircraft  simulator  for  the  Avionics  Directorate  at  Wright  Laboratory  (WL), 
Wri^t-Patterson  AFB.  The  Avionics  Directorate  is  the  Air  Force  research  laboratory  for  advanced 
avionics  concepts.  Current  research  areas  include  multiprocessor  architectures,  defensive  avionics,  and 
integrated  communication,  navigation  and  identification  (CNI)  systems.  The  Avionics  Directorate  is 
actively  working  to  integrate  its  facilities  so  that  systems  arul  concepts  can  be  developed,  tested,  and 
evaluated  in  a  multispectral  environment  The  ITB  simulator  is  the  vehicle  for  advanced  testing.  It  is  an 
ettgineering  level  simulator  that  is  easily  reconfigurable  to  play  the  role  of  many  different  aircraft  The 
ITB  simulator  features  fully  programmaUe  flight  dynamics  capability,  an  out-the-window  display,  terrain, 
and  avionics  displays.  Operational  systems  such  as  electronic  sensors  and  weapons  can  be  added  based 
on  the  desired  af^licadon.  The  ITB  simulator  supports  man-in-die-loop  testing  for  systems  and  concepts 
in  software  based  simulations. 

Although  DIS  ct^rability  has  been  implemented  in  several  aircraft  simulators,  there  has  been  little  rigorous 
analysis  of  the  ability  of  DIS  to  perform  aerial  combat  and  air  mission  support  roles.  The  ITB  is  hi^y 
qualified  to  support  testing  in  diis  area.  The  ITB  can  simulate  F-ISE,  A-7D,  and  C*130  aircraft  and  other 
airframes  could  be  supported  at  modest  cost.  Ihe  Flight  Dynamics  Directorate,  also  at  Wright-Patteison 
AFB,  is  in  the  process  of  adding  DIS  capability  to  some  of  their  experimental  aircraft  simulators.  The 
Flight  Dynamics  Directorate  simulators  are  also  reconfigurable  and  used  to  model  advanced  aircraft 
designs.  Since  the  Avionics  Directorate  and  the  Flight  Dynamics  Directorate  are  closely  located,  there  is 
a  unique  opportunity  to  perform  basic  research  with  DIS  in  a  timely  and  cost-effective  marmer.  Amherst 
Systems  plans  to  support  coordinated  testing  using  DIS  with  the  Avionics  Directorate  and  the  Flight 
Dynamics  Directorate.  The  ITB  would  then  be  used  in  a  joint  services  training  exercise  in  a  close  air 
support  mission,  applying  knowledge  gained  from  the  tests.  Many  benefits  will  be  gained  from  this 
t^ioach,  including: 

a.  To  succeed  in  modem  combat,  cooperation  among  the  aimed  services  is  vital.  Most 
training  efforts  to  date  using  DIS  have  been  performed  by  the  Army  only.  This  project 
dononstrates  Air  Force  commitment  to  DIS  and  joint  services  training  efforts. 

b.  The  project  will  advance  basic  understanding  of  the  operation  of  DIS.  It  is  expected 
that  requirements  for  aerial  combat  will  stress  its  capability.  Important  knowledge 
about  its  limitations  and  techniques  to  avoid  them  will  be  gained.  Areas  that  require 
further  study  will  be  noted  and  suggestions  on  possible  improvements  will  be  made. 

c.  The  advanced  capabilities  of  the  simulators  used  in  the  tests  means  that  these  modem 
aircraft  simulators  could  be  used  in  training  exercises.  This  provides  a  cost-effective 
method  of  testing  the  capabilities  of  different  aircraft  in  realistic  roles.  Other  services 
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will  have  the  opportunity  to  train  with  air  support  rq>tesenting  advanced  Air  Force 
capability.  This  could  be  especially  relevant  for  special  forces  training. 

d.  The  rectmfigurable  capabilities  of  the  laboratories  can  provide  training  for  specialized 
missions  that  cannot  be  supported  by  point  design  simulators. 

e.  Implementation  of  DIS  in  simulators  such  as  the  ITB  promotes  synergism  and 
cooperation  between  the  research  and  training  branches  of  the  arnied  forces,  groups 
that  normally  operate  independently. 

IJZ  Summary  of  Results 

This  section  summarizes  the  work  to  date  on  this  SBIR  Phase  I  project 
1  J.1  Work  Plan 

In  order  to  investigate  the  feasibility  of  adding  DIS  capability  to  the  ITB  simulator  during  this  effort  a 
work  plan  was  developed.  The  objectives  of  the  work  plan  were  to  identify  the  requirements  for  adding 
DIS  capability  to  the  ITB  and  to  develop  a  design  that  would  satisfy  these  requirements.  At  this  point  it 
is  be  possible  to  determine  cost  and  schedule  for  implementing  the  capability.  A  Phase  n  proposal  has 
been  submitted  to  the  program  sponsors. 

The  adopted  work  plan  is  as  follows: 

a.  Study  the  ITB  to  understand  its  functionality. 

b.  Study  die  DIS  PDU’s  and  understand  their  usage. 

c.  Derive  system  requirements  for  adding  DIS  capability  to  the  ITB. 

d.  Evaluate  the  data  items  in  each  transmitted  PDU  and  identify  their  source  in  the  ITB 
modules.  Evaluate  the  data  items  in  each  received  PDU  and  identify  their  destination 
and  use  in  the  ITB  modules. 

e.  Develop  interface  requirements,  both  for  exchanging  data  among  1TB  modules  and  for 
cminecting  the  ITB  to  other  DIS  sites. 

f.  Produce  a  top-level  design.  The  modules  and  data  structures  affected  by  the 
enhancement  of  the  ITB  to  include  DIS  capability  will  be  identified.  Pseudo-code 
examples  are  given  for  some  important  functions  (for  example,  see  Figure  2.3.2. 1 .2-2). 

Items  (a),  (b)  and  (c)  were  completed  by  April  30,  1992.  A  complete  discussion  of  these  items  is 
contained  in  Appendix  A  of  the  documoit  “Simulator  Networking  Phase  I,  Contractor’s  Progress,  Status 
and  Management  Plan,  February  1,  1992  Through  April  30,  1992”,  previously  submitted  during  this 
program.  Section  2.1  presents  the  results  of  this  earlier  work.  The  other  items  are  discussed  in  detail  in 
the  remainder  of  this  report 

122  Results  of  Analytic  Efforts 

The  objectives  of  the  work  plan  have  been  achieved  in  this  Phase  I  project  A  Phase  n  proposal  has  been 
submitted  to  the  program  sponsors  in  which  the  tasks,  cost  and  sd^ule  for  implementing  DIS  capability 
in  the  ITB  has  bc^  justified.  A  summary  of  the  results  of  the  tasks  from  the  work  plan  is  given  below. 
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a.  Study  the  ITB.  Amherst  Systems  received  extensive  documentation  about  the  ITB 
from  WL/AAAS-2.  The  documents  were  studied,  and  an  understanding  of  tte 
architecture  and  functional  organization  of  the  ITB  was  gained.  Mr.  John  Woodyard. 
ITB  technical  liaistm  at  Wright  Laboratory  was  extremely  helpful  in  providing 
documentation  and  answering  questions  about  ITB  operation.  Refer  to  Aiqmdix  A.40 
of  the  interim  repoit  for  detailed  information  about  the  ITB. 

b.  Study  the  DIS  PDU's.  Each  of  tte  DIS  PDU‘s  was  studied.  The  fields  of  each  PDU 
were  examined  and  the  types  of  data  for  each  were  identified.  Of  particular 
importance  were  the  coordinate  systems  used  in  most  of  the  PDU’s,  and  the  dead 
redconing  infoimatioa  The  Institute  for  Simulation  and  Training  (1ST)  was  consulted 
on  several  occasions  and  was  very  helphil.  Appendix  A.SO  of  the  interim  report 
presoits  this  information. 

c.  Derive  system  requirements  for  adding  DIS  capability  to  the  ITB.  Before  this  task 
could  be  addressed,  a  mission  and  configuration  for  the  ITB  had  to  be  decided  in  order 
to  focus  the  work  for  a  realistic  Phase  II  project.  It  was  detennined  that  the  close  air 
support  mission  would  be  an  appropriate  role.  Since  most  DIS  training  applications  to 
date  have  been  ground  battles,  the  ability  to  provide  robust  close  air  support  would 
greatly  enhance  the  realism  and  scope  of  the  training.  The  following  ITB 
coiiiguration  is  considered  appropriate  for  this  mission: 

•  F-15E  Airframe 

•  Out-the-Window  (OTW)  Display 

•  Fbrward  Looking  Infrared  (FLIR)  Sensor/Display 

•  Head’s-Up  Display  (HUD) 

•  Laser  Ranger  Sensor 

•  MK-82  Weapon  System 

•  Basic  Navigation  Avionics 

The  requirements  for  implementing  this  capability  were  developed.  It  was  determined 
that  the  Entity  State  PDU  was  the  most  important,  and  that  the  Fire  PDU,  Detonation 
PDU  and  CoUsion  PDU  will  also  be  implemented.  The  Repair^esupply  PDU’s  will 
be  implemented  only  in  rudimentary  form  since  the  ITB  will  not  have  this  capability. 
The  experimental  PDU’s  will  not  be  implemented  in  Hiase  II.  The  requirements  to 
support  the  selected  PDU’s,  the  ITB  functions,  and  connectivity  to  other  DIS  sites, 
were  developed.  Important  areas  addressed  include  gaming  area,  participants,  the 
message  interface,  coordinate  transfoimatior  .  dead  reckoning,  and  time.  The  system 
requirements  are  discussed  in  detail  in  Appendix  A.60  of  the  interim  report. 

d.  Evaluate  PDU  data  items.  The  selected  DIS  PDU’s  were  re-examined.  The  fields  of 
each  were  analyzed  to  determine  their  source  of  information  in  the  ITB  (for 
transmitted  PDU’s),  or  used  and  destination  (for  received  PDU’s).  Section  2.2  of  this 
report  discusses  the  PDU  data  items. 

e.  Develop  interface  requirements.  External  interface  requirements  were  developed  for 
linking  the  1TB  to  other  DIS  sites  and  sources  of  data.  The  external  connections 
include  a  GPS  receiver  module  for  Universal  Coordinated  Time,  the  Automated 
Forces  Testbed  for  testing,  and  other  DIS  sites  for  training  missions.  The  data 
interchange  within  the  ITB  was  examined.  New  requirements  to  support  DIS 
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CjqntNlity  affected  the  types  of  data  exchanged  among  FTB  tasks.  New  data  structures 
to  hold  DIS  related  information  were  developed  and  the  types  of  data  elaborated. 
Performance  requirements  for  ITB  software  were  derived.  The  interface  and 
perfonnance  requirements  are  presented  in  Section  2.3. 

f.  Produce  tqvlevel  design.  New  tasks  to  support  DIS  capability  have  been  desigited. 

The  interrelationships  between  existing  ITB  tasks  and  the  new  tasks  have  been 
devdoped.  This  report  elaborates  on  the  functionality  of  tire  rrew  tasks  as  well  as  the 
enharreements  that  must  be  made  to  the  existing  tasks.  Perhaps  the  most  important 
technical  challenge  for  Phase  n  is  to  reconcile  the  WGS-1984  ECEF  coordinates  used 
in  DIS  with  the  coordinate  systems  used  in  the  ITB  and  its  BBN  OTW/FLIR  displays. 

This  is  critically  important  for  proper  scenario  representation.  A  detailed  discussion  of 
the  issues  related  to  coordinate  transformation  is  provided  in  Section  2.4. 

U  Conclusions 

Pertu^  the  most  important  conclusion  derived  from  this  study  is  that  implementation  of  DIS  capability  in 
the  riB  simulator  is  feasible.  The  analytic  work  performed  in  Hiase  I  substantiates  this  conclusion.  The 
requirements  for  adding  DIS  capability  and  a  design  that  implements  these  requirements  have  been 
developed.  What  is  significant  atout  this  work  is  that  the  ITB  is  easily  reconfigurable  to  simulate  many 
types  of  aircraft  and  their  operational  systems.  The  ITB  is  an  ideal  simulator  to  suj^rt  research  in  this 
area  as  well  as  participate  in  training  programs  that  require  advanced  Air  Force  capability. 
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Section  2 

ANALYTIC  RESULTS 


2.1  Previous  Results 

This  section  summarizes  the  results  of  analysis  performed  in  the  February  1  to  April  30  time  period. 
These  results  are  fully  documented  in  “Simulator  Networking  I%ase  I.  Contractor’s  Progress,  Status,  and 
Managemem  Plan,  February  1, 1992  Through  April  30, 1992. 

2.1.1  Introdut^on  to  the  Integrated  Test  Bed  (ITB)  Facility 

The  ITB  facility  tests  and  evaluates  advanced  avionics  architectures  and  equipment  for  laboratory 
experimentation  requiring  a  full  mission  simulation.  The  facility  includes  a  realistic  crewstatioa  mock-up 
with  the  elements  of  digital  avionics  operating  as  they  would  in  a  real  military  aircraft  Out-the-Window 
(OTW)  scene  generation  is  also  provided,  giving  the  pilot  a  symbolic  background  scerte  outside  the 
crewstation  for  visual  orientation  necessary  to  locate  items  such  as  targets,  runways,  and  waypoints.  Key 
ITB  sujqxrrt  equipment  includes  the  facility  processors  and  systems  and  their  resident  so^are,  whi(^ 
provide  the  test  control,  monitoring,  and  simulation  necessary  to  perform  avionics  system  evaluatitms  and 
demonstrations.  Tlie  following  are  the  important  facility  processors  and  systems: 

a.  Simulation  Host  Processor  Complex:  Hie  simulation  software  resides  on  three  Harris 
host  processors  with  shared  memory.  It  simulates  a  selected  aircraft,  its  environment, 
sensors,  and  wet^ns  subsystems,  and  performs  data  collection  and  evaluation.  The 
simulation  provides  real-time  inputs  to  the  crewstation  and  to  mission  software  via  the 
Multiplex  Bus  Terminal  (MBT)  and  MIL-STD-1553B  multiplex  data  bus.  The  Harris 
host  processors  are  currently  being  upgraded  to  an  Alliant  computer  system. 

b.  Generalized  Avionics  Simulation/Integration  System  (GENASIS):  The  GENASIS  is  a 
crewstation  mock-up  employing  two  processors  to  provide  realistic  pilot  interfaces 
through  integrated  displays,  command  entry  keyboards,  backup  instruments,  and 
aircraft  controls  (i.e.,  stick,  rudder,  and  throttle).  Resident  software  on  the  MicroVAX 
processor  provides  control  of  input  and  output  data  from  the  Harris  complex  to  the 
crewstation  via  Direct  Memory  Access  (DMA).  Resident  software  on  the  MicroVAX 
in  processor  provides  communication  with  the  MIL-STD-1S33B  dau  bus  via  the  Bus 
Interface  Unit  (BIU). 

c.  OTW  Scene  Generation  Complex:  The  BBN  display  system,  video  control  system, 
and  their  respective  resident  software  provide  various  visual  background  scenes  along 
with  a  simulated  Head-Up  Display  (HUD). 

The  Model  Simulation  System  (MSS)  provides  the  simulation  of  avionic  sensors,  weapon  subsystems, 
and  an  airhame/envirorunent  for  a  military  aircraft  performing  a  Gose  Air  Support  (CAS)  mission. 
Rgure  2. 1.1-1  shov  ,  an  overview  of  the  MSS.  The  MSS  employs  the  Availability  Demonstration 
Simulation  Sui^it  (ADSS)  Executive  as  its  simulation  executive. 
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Figure  2. LI -I  Overview  of  MSS  Software 
The  MSS  consists  of  the  five  following  functional  types  of  software: 

a.  ADSS  Executive:  The  ADSS  Executive  controls  the  simulation,  interfaces  the 
simulation  with  bus  input/output  (I/O),  and  provides  checkpoint/restart  capability  to 
reset  the  ^uladon  to  a  previous  time  in  the  scenario. 

b.  Sensor  Simulation  Models:  The  Sensor  Simulation  Models  simulate  the  on-board 
aircraft  sensor  systems. 

c.  Wetqpon  Delivery  Simulation  Models:  These  Models  simulate  functional  responses  of 
wet^xm  systems  to  the  operational  stores  management  software. 

d.  Aircraft/Envirorunent  Simulation  Models:  The  Aircraft/Environment  Models  provide 
airftame  dynamics,  flight  control  dynamics,  and  propulsion  informatiorL 

e.  Interface  Utilities:  The  Interface  Utilities  provide  access  to  the  crewstation  cociq>it 
controls  and  displays,  and  the  OTW  generation  complex. 

In  addition,  the  MSS  includes  the  Scenario  Generator/Acceptance  Test  Program.  This  software  replaces 
die  aircraft  environment  models  by  providing  idealized  navigation,  guidance  and  aircraft  dynamics  for 
MSS  testing. 
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UJ,  System  Requirements  Summary 

The  system  requirements  for  implementing  DIS  capability  in  the  1TB  were  discussed  in  detail  in  the 
document  “Simulator  Netwoiking  Phase  I,  Contractor’s  Progress,  Status  and  Management  Plan”.  As  a 
result,  this  section  win  summarize  the  findings. 

a.  Ctmnect  the  FTB  to  a  long-haul  network.  The  Integrated  Test  Bed  Facility  in  Building 
620  at  Wiight-Patterson  AFB  is  not  currently  connected  to  any  long-haul  network  that 
can  support  DIS.  There  is  a  T-1  line  connection  on  base  to  the  Air  Force  Institute  of 
Technology  (AFTT).  A  fiber  0[Hic  link  exists  between  Building  620  and  AFTT,  but  a 
dedicated  connection  must  be  made  to  unite  the  resources.  Figure  2.12-1  illustrates 
required  connectivity  among  Wright-Patterson  AFB  facilities,  much  of  which  is  either 
planned  or  already  in  place. 


Figure  2.12d  Connectivity  Among  Wright-Patterson  AFB  Facilities 

b.  Sdectability  of  operation.  The  operator  should  be  able  to  select  between  DIS  and  rx>n- 
DIS  operation.  The  ITB  must  continue  to  be  able  to  support  Wright  Laboratory 
projects  after  it  has  been  augmented  with  DIS  capability. 

c.  Gaming  area.  The  gaming  area  must  be  selectable  by  the  operator.  This  will  be 
coordinated  with  other  DIS  participants  before  scenario  execution  begins.  Terrain  data 
corresponding  to  the  selected  gaming  area  must  be  used.  Concerns  that  must  be 
addressed  related  to  gaming  selection  are  listed  below.  Many  of  these  concerns 
represent  general  simulation  problems.  Project  2851  is  currently  addressing  these 
items. 

•  Terrain  and  Underlying  Earth  Models.  The  ITB  software,  the  aircraft  avionics, 
and  the  OTW  display  all  use  independent  algorithms  to  model  the  earth  and  its 
terrain.  These  models  must  be  reconciled. 

•  Gaming  Area  Effects:  Surface  characteristics  affect  sensor  responses.  For 
example,  flying  through  mountainous  terrain  produces  multipath  effects  in  RF 
sensors.  The  systems  models  used  in  the  1TB  must  be  able  to  account  for  terrain 
effects. 
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•  Cultural/Environmental  Interactions;  Cultural  and  environmental  features  affect 
detectaUlity  in  obvious  ways.  For  instance,  a  tank  convoy  that  would  be  visiUe 
at  great  distance  in  the  desert  could  be  virtuaUy  invisible  in  a  forested  area.  The 
visual  displays  and  sensor  models  must  account  for  this. 

•  Commonality  of  Simulators;  This  a  concern  with  all  DIS  s^licadons.  Even  if 
common  environment,  terrain  and  cultural  databases  are  used,  differences  in 
interpretation  can  invalidate  scenario  results.  Typical  problems  involve  line*of> 
si^t,  camouilage/appearance  and  resolution. 

d.  Participants.  The  ITB  must  be  able  to  realistically  represent  all  participants  in  the 
scenario.  This  is  critically  important  for  all  sensing  functions,  including  the  out-the* 
wiixlow  display.  If  visual  coi^irmation  is  required  before  engagement,  the  ITB  must 
provide  sufficient  detail  to  perform  this.  There  are  several  aspects  to  entity 
presentation.  The  first  is  a  rustic  silhouette,  which  is  often  provided  with  wire¬ 
frame  diagrams.  The  second  is  static  contrast/reflectivity/emissitivity.  Tanks  ^uld 
be  realistically  colored,  and  aircraft  should  presem  accurate  radar  cross-sections.  The 
third  is  that  the  articulated  parts  need  to  be  properly  represented,  if  required.  From  a 
sensing  point  of  view,  the  ITB  should  be  able  to  produce  realistic  cross-sections  in  all 
spectra  for  all  participants/aspect  angles  as  well  as  for  cultural  and  environmental 
features. 

e.  General  Conduct.  Procedures  must  be  established  for  executing  DIS  scenarios.  These 
procedures  include  establishing  the  type  of  player  and  mission  the  ITB  will  represent, 
procuring  terrain/environmental  databases,  checking  out  the  communication  link, 
coordinating  with  the  “allied  commander”  and  other  players,  configuring  the  ITB,  and 
starting  execution  at  the  prescribed  time. 

f.  Sending  and  Receiving  DIS  Messages.  The  ITB  must  be  capable  of  sending  and 
receiving  messages  using  DIS  protocol  data  units.  It  is  helpful  to  look  at  this 
ctqrability  as  being  performed  at  three  levels;  physical,  logical  and  virtual. 

•  Physical:  There  must  be  interface  hardware  to  establish  tl^  link.  The  physical 
link  includes  all  tte  cabling  and  processor  boards  required  to  transmit  and  receive 
thePDU’s. 

•  Logical;  The  logical  link  represents  the  software  drivers  and  control  processes 
that  must  be  developed  to  control  the  physical  link.  The  logical  link  must  operate 
with  minimal  delay.  It  is  anticipated  that  a  driver  will  exist  for  the  interface 
hardware,  but  that  additional  software  will  be  required  to  provide  efficient 
processing  within  the  ITB. 

•  Virtual:  The  virtual  link  allows  the  ITB  software  to  operate  with  read/write  PDU 
functionality.  This  operates  at  OSI  level  7  and  is  independent  of  the  underlying 
hardware  interface. 

g.  Message  Generation.  The  ITB  must  be  capable  of  generating  PDU’s  for  each  function 
that  it  can  perform.  Table  2. 1.2-1  maps  functionality  to  PDU  generation  capability. 
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Table  2.1 2-1  PDV  Generadon/CapabiUty  Cross  ReSerttiee 


HIKSH 

PDU 

AlwiytiequiKd 

Entity  State,  Collision 

Weapon  finng 

Fire,  Detonation 

Renqiply 

Resiqjply  Offer.  Resupply  Cancel 

Receive  supidiec 

Service  Request,  Resupply  Received.  Restqjply  Cancel 

Rqiair 

Repair  Conq>lete 

Receive  repairs 

Service  Request.  Repair  Response 

f.  Message  Reception.  The  ITB  shall  be  capable  of  receiving  PDU*s  of  any  type. 
Undefined  PDU’s  (PDU  Type  other  than  1  through  10)  will  be  ignored.  Table  2.1.2-2 
summarizes  the  actions  that  will  be  taken  in  response  to  the  defined  PDU’s. 


Table  2.12-2  Actions  for  Received  PDU*s 


Received  PDU 

Action 

Entity  State 

Create  the  entity  if  it  has  not  been  seen  before.  Use  infoimation  from  the  entity  ^pe  datahesr  to 
determine  what  to  do  with  the  dau  from  the  PDU.  Update  visual  and  sensor  ptocessina  and 
displays.  Reset  dead  reckoning  for  the  entity. 

Fire 

Represent  muzzle  flash  effects  if  necessary. 

Detonation 

Detennine  damage,  visual,  sensor  effects  on  1TB. 

Collision 

If  collision  is  with  ITB  and  ITB  has  comparably  determined  that  a  collision  has  occuired,  calculate 
effects  on  li  b. 

Service  Request 
Resui^ly  Offer 

Resu{^  Received 
Resupfdy  Cancel 

Rqtair  Complete 

Repair  Response 

The  ITB  will  have  no  rqiair/resupply  capability.  If  a  Service  Request  PDU  is  received,  the  ITB  will 
respond  that  it  is  unable  to  provide  supplies  or  repairs.  Receipt  of  the  other  PDU’s  will  be  ignored. 

i.  Coordinate  Transformations.  The  DIS  standard  for  entity  location  is  earth-centered 
earth-fixed  (ECEF)  coordinates  based  on  the  centroid  of  the  WGS-1984  earth  using 
the  IEEE  7S4-198S  standard  for  floating  point  numbers,  in  units  of  meters.  'The  FTB  is 
currently  being  upgraded  from  spherictd  to  WGS-1984  earth,  and  software  is  being 
transferred  from  Harris  to  Alliant  computers.  The  ITB  dociunentation  has  not  yet  been 
modified  to  reflect  the  changes.  What  is  most  important  is  that  each  of  the  software 
components  and  hardware  display  units  use  equivalent  earth  interpretations.  The 
affected  components  are  the  ITB  flight  software,  munition  trajectory  calculations,  die 
OTW/FLIR  display  and  the  HUD.  TIk  following  transformations  must  be  performed: 
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•  ECEF/enti^  to  OTW/FLIR  locatioo/orientation 

•  1TB  aircraft  location/orientation  to  OTW/FLIR  locadon/orientation 

•  ITB  aiiciait  locatitMn/oriemation  to  HUD  location/orientaticm 

It  may  be  necessary  to  derive  transfonnations  to  reconcile  difTermt  coordinate 
systems.  For  exami^,  to  convert  from  WGS-1984  to  ^^rical  earth  requires  knowing 
the  radius  of  the  Sf^rical  earth  to  ensure  that  the  entity  is  in  die  smne  location  in  both 
coordinate  systems.  Velocity  and  orientation  may  also  require  transformation  since,  in 
WGS-1984  earth,  unlike  sfdierical  earth,  one  degree  of  latitude  is  not  a  constam 
distance  and  down  does  not  always  poim  to  the  center  of  the  earth.  Unless  these 
conditions  are  properly  handled,  realistic  simulation  cannot  occur. 

j.  Dead  Reckoning  of  ITB  Managed  Entities.  Dead  reckoning  is  performed  on  ITB 
managed  entities  to  determine  when  to  issue  Entity  State  PDU's.  Eadi  Entity  State 
POU  contains  dead  reckoning  information  to  allow  other  sites  to  update  the  location 
and  orientation  of  the  entity  betweoi  PDU’s.  Before  simulation  begins,  each  entity  is 
assigned  diree  threshold  v^ues  -  location,  orientation  and  time.  An  entity  must  issue 
and  Entity  State  PDU  if  one  of  the  following  situations  occurs.  The  situations  apfdy 
bodi  to  the  basic  entity  and  any  of  i&  articulated  parts.  It  should  be  noted  that  the 
Entity  State  PDU  can  be  issued  for  other  reasons  also  (e.g.  change  in  appearance). 

•  Its  actual  location  differs  ffom  its  dead  reckoned  location  by  more  than  the 
dueshold. 

•  Its  actual  orientation  differs  form  its  dead  reckoned  orientation  by  more  dran  the 
threshold. 

•  The  elapsed  time  since  the  most  recem  Entity  State  PDU  was  issued  exceeds  tire 
time  threshold. 

To  implement  the  thresholding,  the  DIS  interface  software  must  perform  dead 
reckoning  calculations  on  the  aircraft  at  the  rate  at  which  it  is  updated  (64  Hz)  and 
compare  results  to  die  actual  values  annpute^  by  the  1TB  operational  software.  When 
a  threshold  is  exceed^;;,  Uie  software  will  generate  an  Entity  State  PDU  and  reset  dead 
reckoning  calculations  with  the  new  %:tual  values.  One  importam  concern  is  whetirer 
the  64  Hz  update  rate  will  cause  excessive  PDU  generation  during  high  G  tactical 
maneuvers.  This  will  be  an  area  of  sCidy  during  the  SBIR  Phase  n  program. 

k.  Dead  Reckoning  of  Other  Entities.  Dead  reckoning  is  used  on  other  entities  to 
determine  their  location  and  orientaticm  at  times  between  their  Entity  State  PDU's. 
The  Entity  State  PDU’s  contain  the  information  required  to  perform  the  dead 
reckoning  calculations.  This  computed  information  will  be  stored  in  the  shared 
memory  conunon  and  provides  data  to  support  the  sensor  an<^  visual  displays.  The 
dead  reckoning  calculations  will  be  performed  at  a  i6  Hz  rate,  to  match  the  OTW  and 
FLIR  updates. 

l.  Hme.  The  DIS  standard  permits  use  of  either  Universal  (Toordinated  Time  or  local 
simulator  (relative)  time.  The  ITB  presently  supports  only  relative  time.  Access  to 
Universal  Coordinated  Time  requires  reception  of  GPS  satellite  signals.  WL/AAAS-2 
is  actively  investigating  whether  the  ITB  can  gain  access  to  this  time  standard.  No 
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matter  vi^ch  time  standard  is  used,  tight  syndironizaticm  amraig  simulator  sites  is  a 
critical  lequiremem.  For  coordinated  aerial  maneuvers,  such  as  welded-wing,  errors  of 
milliseamds  could  cause  a  collision.  The  effects  of  time  errors  will  be  a  subject  of 
serious  study  during  Fhase  n. 

12  Analysis  of  PDU’s 

DIS  entides  interaa  with  each  other  through  an  exchange  of  messages  also  ktmwn  as  protocol  dau  units 
(PDU’s):  The  DIS  standard  consists  of  ten  PDU’s,  as  listed  in  Table  2.2-1. 


Tabu  22-1  Standard  DIS  PDVs 


Value 

PDU  Kind 

Descriptkm 

1 

Entity  State 

Information  about  an  entity 

2 

Fire 

I^rina  of  a  weapon 

3 

Detonation 

Detonation  or  impact  of  monition 

4 

CoUiaian 

CoUiaiaiu  between  cnddea 

5 

Service  Requeat 

Requeat  for  logiaticc 

6 

Reaqiply  Offer 

Offering  of  auppliea 

7 

Reaupply  Received 

Receipt  of  auppliea 

8 

Reatqtply  Cancel 

Cancdlation  of  aervice  requeat 

9 

Repair  Complete 

Completion  of  repain 

10 

Rqwtr  Re^xmse 

Adoiowledgment  of  rqnir  conqjletion 

The  Entity  State,  Fire,  Detonation,  and  Collision  PDU’s  are  important  to  FTB  operation.  The  Entity  State 
PDU,  which  represents  motion  and  appeanmce  of  the  simulated  aircraft,  is  most  critical.  The 
Rcpair/Resupply  PDU’s  (values  5  to  10)  will  be  supported  only  to  the  extent  that  the  FTB  will  respcmd 
correctly,  den^g  the  capability,  should  other  entities  request  these  ser/ices.  It  should  be  noted  here  that 
a  numbN  of  temporary/experimental  PDU’s  are  included  in  the  DIS  standard.  Some  of  them,  particularly 
the  emissions  related  PDU’s,  are  strongly  related  to  ITB  operation.  However,  since  these  PDU’s  are  still 
undergoing  testing  and  have  not  been  formally  approved,  no  analysis  on  them  has  been  performed  to  date. 

Analysis  of  tiie  PDU’s  has  been  categorized  as  transmitted  and  received.  The  processing  requirements  for 
the  trananissicm  and  receipt  of  PDU’s  are  quite  different  Being  DlS-compliant  means  being  aUe  to 
transmit  PDU’s  as  defined  in  the  draft  standard.  A  early  key  goal  in  the  Phase  II  implementation  will 
make  the  ITB  DIS-compliant  But  this  alone  does  not  guarantee  that  the  ITB  can  be  a  meaningful 
participant  in  training  scenarios.  There  are  open  questions  as  to  whether  the  DIS  protocol  can  realistically 
support  a  fast  mover  such  as  the  ITB  in  aerial  combat  and  close  air  support  missions.  Additionally,  for 
the  ITB  to  perform  realistically,  the  received  PDU’s  must  be  processed  in  a  timely  manner  aiKl  ttteir  data 
seamlessly  injected  into  the  FTB  programs  and  routines. 

The  DIS  interface  has  functionality  independent  of  that  of  the  ITB  cockpit  In  other  words,  the  FTB 
operation  should  appear  the  same  whether  entities  are  generated  in  an  intenuil  scenario  or  created 
externally  through  DIS.  The  act  of  sending  and  receiving  PDU’s  is  an  obvious  DIS  interface  function  in 
that  it  has  no  direct  effect  on  the  ITB  activity.  As  another  examine,  the  DIS  protocol  states  that  an  Entity 
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State  PDU  must  be  generated  whenever  the  dead  reckoned  position/orientation  and  actual 
positkxi/orimitation  vary  by  more  than  a  certain  amount  This  is  quite  independent  of  the  aero  models 
used  to  simulate  ITB  motion.  In  fact,  a  special  process  dedicated  to  monitoring  the  variation  will 
probably  be  required.  Yet  another  example  is  the  coordinate/unit/rq>resaitati(m  transfonnations  to  and 
from  riB  and  DIS  variables.  Many  of  the  DIS  functions  will  be  supported  in  independently  executing 
tasks  running  in  parallel  to  the  baseline  ITB  tasks.  Section  2.4  describes  the  approach  in  further  det^. 

2.2.1  Transmitted  PDU’s 

The  Entity  State  PDU  is  the  most  critical  to  the  early  stages  of  testing  close  air  support  scenarios.  If  the 
opposing  forces  are  to  aa  in  a  realistic  marmer  (e.g.,  taking  cover,  firing  defrosively),  the  ^rpearanoe  of 
the  ITB  must  be  represented  in  the  opposition  forces  simulators  with  high  fidelity.  The  actual 
representation  within  those  simulators  is  beyond  tte  scope  of  this  project.  However,  the  ITB  will  be 
responsiUe  for  generating  accurate  and  timely  Entity  State  PDU’s.  When  the  ITB  is  able  to  accompli^ 
this,  open  questions  about  fidelity  can  be  addressed.  The  critical  issue  is  whether  ITB  activity 
(particularly  movement)  can  be  represented  realistically  in  other  simulators.  Some  of  foe  key  variables  in 
foe  analysis  are  as  follows: 

a.  Location  and  orientation  thresholds  for  PDU  generatioa 

b.  Communication  and  processing  latoicies. 

c.  Terrain  and  feature  represenution/correlation  (particularly  important  for  low  level 
fligjits). 

Some  of  the  important  observations  that  will  be  included  in  foe  analysis  are  as  follows: 

a.  Location/oiientation  errors  over  time. 

b.  “Jumping”  of  position  as  PDU  ’  s  are  received. 

c.  Amount  of  message  traffic. 

Another  consideration  in  ITB  modeling  is  foe  use  of  articulated  parts.  The  reason  for  modeling  the 
articulated  parts  is  that  other  players  can  detect  and  react  to  their  settings.  Conversely,  if  they  canmt  be 
detected  and  they  have  no  effect,  there  is  no  need  to  model  them.  The  wing  stations  could  be  represented, 
if  for  no  other  reason  than  realistic  visual  presentation  in  high  resolution  simulators.  The  ITB  internal 
software  area  model  also  represents  aircraft  components  such  as  fl^s  and  the  speed  brake.  Articulated 
parts  on  the  ITB  will  not  be  implemented  in  Phase  H.  The  Phase  n  Final  Report  will  discuss  whether 
articulated  parts  would  have  improved  functionality  and  also  analyze  how  they  could  be  implraiented. 

The  ITB  could  potentially  model  more  than  foe  aircraft  itself.  The  ITB  software  sui^rts  the  modding  of 
Maverick  missUe  firing  and  flight,  although  this  capability  is  not  yet  fuUy  implemented.  If  the  missile 
were  detectable  by  other  players,  it  would  need  to  be  represented  as  an  independent  entity  in  DIS. 
Maverick  missile  capability  will  not  be  implemented  during  Phase  II.  However,  the  DIS  interface 
software  will  be  developed  in  such  a  manner  that  additional  entities  could  be  supported  at  a  future  date. 

The  Collision  PDU  is  important  in  low-level  flight  and  when  aircraft  fly  in  formation.  Representation  of 
terrain  and  cultural/envirorunental  features  take  on  great  significance  when  low-level  flying  inherent  in 
close  air  support  missions  is  considered.  Collision  detection  will  be  implemented  by  placing  an 
imaginary  shell  around  each  entity.  If  the  shells  overlap,  a  collision  will  have  occurred. 

Analysis  of  the  transmitted  PDU’s  is  summarized  in  the  following  tables.  SourceA^alue  columns  in  the 
tables  aruiotated  “n/a”  are  not  applicable  to  the  Phase  II  work  but  may  be  added  in  future 
implementations.  SourceA^alue  coluirms  annotated  “**"  means  that  these  values  are  assigned  before  foe 
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exadse  and  will  remain  constant  during  the  entire  period  of  the  exercise.  Report  Sectitxi  and  Appendix 
references  in  die  taUes  are  for  the  DlS-standards  document  “Protocol  Data  Units  for  Entity  Informadoo 
md  Entity  Interaction  in  a  IMstributed  Interactive  Simulation.”  Table  2.2.1-1  provides  a  cross-reference 
between  PDU  figure  definitions  in  the  DlS-standaids  document  and  the  tables  in  this  section. 


Tabu  22.1-1  Transmit  PDV/Table  Cross-Reference 


PDU 

DlS-Standards  Figure 

Table  Number 

Enii^  State 

5-19 

2.2.1 -2 

Hk 

5-20 

12.1-3 

Detonation 

5-21 

2.2.M 

QtUiiion 

5-28 

12.1-5 

Reaqtply  Cancel 

5-25 

111-6 

Repair  Complete 

5-26 

111-7 
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Table  2  J. I -2  Transmit  PDU:  Entity  State 


FMd 

Source 

Activity/Notes 

Source/VahM 

FfPtoclii  VvntM 

Fixed 

Assigned  before  exercise 

EnfciMUMitfkr 

Fixed 

Assigned  before  exercise  (4.7.1.2) 

PDU  Type 

Rxed 

Constant  1 

1 

Eattly  Ucatificr 

Assigned  by  DIS  interface  for  ITB  cockpit  and 
each  other  entity  created  by  1TB  software. 

SiteUentifier 

Fued 

Assigned  by  audiority  managing  DIS  exercises 

Hott  Identifier 

Fued 

Assigned  by  authority  managing  DIS  exercises. 
One  site  nuy  have  several  hosts. 

Eatiiy  Identifier 

Fixed  at  entity 
creation 

Each  entity  created  by  host  has  its  own  unique 
entity  identifier. 

1 

Force  Identifier 

Fxed  at  entity 
creation 

Enumerated  type,  ^ipendix  E30.1.1 

1 

EatiqrType 

DIS  interface  must  know  about  types  of  entities 
that  ITB  can  create. 

Enti^Kind 

Fixed  at  entity 
creatkm 

Enumerated  type.  Appendix  H130.1 

1 

Domain 

Rxed  at  entity 
creatkm 

Enumerated  type,  value  depends  on  entity  kind. 
Appendix  HlJO.l  subsections 

2 

Country 

Fixed  at  entity 
creation 

Enumerated  type,  zero  for  environmental  and 
cultural  feature  entity  kind,  ^ipendix  F30.1.2 

16S 

Categoiy 

Fixed  at  entity 
creation 

Enumerated  type 

Platform:  Appendix  H2.30.2 

Munition:  Appendix  H2303 

Life  Form:  Appendix  H130.1.33 
Environment^:  ^tpetidix  H130.1.43 
Cultural:  ^tpendix  H130.133 

1 

SubcatBgoty 

Hxed  at  entity 
aeatkm,  possibly 
modified  due  to 
attrition 

Enumerated  type,  (aJt.a.) 

Platform:  (Designation)  H230.2 

Munition:  (Designation)  H2303 

Life  Form:  (Designation)  H130.13.3 
Environmental:  (Size)  HI30.1.43 

Cultural;  (Size)  H1.30. 1.53 

7 

Specific 

Fixed  at  entity 
creation,  possiUy 
modified  due  to 
attrition 

Enumerated  type,  (aJuu) 

Platform:  (Model)  H2303 

Munition:  (Model)  H2303 

Life  Form:  (Number)  H130.133 
Environroental:  (Unused)  H130.1.43 
Cultural:  (Unused)  H130.133 

n/a 

Extra 

Fixed  at  entity 
creation 

Not  used  for  any  entity  kind 

n/a 
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Table  22.1-2  Transnut  PDV:  Entity  State  -  (Continued) 


AHmwteEatitjTypc 

EuiqfKjiiil 

Doniaiii 

Countty 

Categoy 

Subcatt^ory 

Specific 

Exn 

Rxedu  entity 
creation,  pocsibk 
modified  due  to 
tttrition 

Same  formats  as  Entity  Type,  puntose  is  that 
some  players  may  have  ahemative  view  of  the 
entity.  Its  use  will  depend  tm  the  requiremenis 
of  others  in  the  simulation. 

n/a 

TIbm  Stamp 

Univenal  Coordinaied 
Time(UTC)or 
mtemal  timulaior 
(relative  tune) 

Indicates  the  time  at  which  the  data  is  valid. 

Up  to  one  hour  cam  be  represented,  units  are 
3600/2^^  seconds.  Bit  zero  is  0  if  relative,  1  if 
UTC.  See  5.2.19.  Represents  time  at  which 

ITB  data  is  valid. 

UTC  will  be  used  if  it  is 
installed. 

Entity  LocatioD 

X-oomponent 

Y-con^xmoit 

Z-oomponejit 

Variable,  based  on 
location  of  a  particular 
part  of  the  entity, 
iqaesentt  dm  origin 
of  the  entity 
coordinate  system 

Geocentric  Cartesian  Coordinates  (World 
Coordinates)  origin  is  the  centroid  of  the  earth, 
positive  x-Bxis  passes  through  Prime  Meridian 
and  Equator,  positive  y-axis  throu^  E90°  and 
Equator,  positive  z-axis  through  North  Pole. 
Each  component  is  64-bit  floating  point, 
conforming  to  IEEE  7S4-198S.  The  shape  of 
earth  is  based  on  World  Geodetic  System  1984 
survey  (WGS-1984).  Units  are  meters.  Based 
on  d^  taken  from  ITB  database. 

Derived  from  ACLATR, 
ACLNGR.ACALTFin 
program  EARTH 

Entity  Linear  Velocity 

X-oonqianem 

Y-oompaiMitt 

Z-component 

Variable,  based  on 
mstantaneous  velocity 
attimeofPDU 

Vector  relative  to  axes  used  to  represent  die 
Entity  Location  (World  Coordinates).  Eadi 
component  is  a  32-bit  floating  point, 
conforming  to  IEEE  754-1985.  Units  are 
meters  per  second.  Based  on  data  taken  from 
ITBdattbase. 

Derived  from  XIDOTF, 
YlDOTF.ZlDOTF.in 
program  AIRPLN 
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Table  22.1-2  TransmiiPDV:  Entity  State  -  (Continued) 


Field 

Source 

Activity/Nates 

Sourcc/Vahie 

Eatttjr  OrieBtadoa 

Psi 

Thca 

Phi 

VariaUe,  based  on 
insumtaneous 
orientatian  at  time  of 
M>U 

Represents  transformation  from  Geocentric 
Cartesian  Coordinates  to  Entity  Coordinates. 
Entity  Coordinaies  origin  at,  the  centtr  of  the 
bourtding  volume,  tndepettdem  of  articulated 
parts.  Positive  x-axis  is  fiom,  positive  y-axis  is 
right,  positive  z-axis  is  down.  (Psi.  Theta,  Phi) 
represent  standard  Euler  angles.  Units  are 
called  Binary  Angle  Measuremem  (BAM)  > 
360A^  degrees.  Based  on  data  taken  from 

ITB  database. 

Derived  from  THETAR, 
ACPHDL  ACPSIR  in 
progrun  AIRPLN 

Dead  Reckoning 
PnranNten 

Parameters  for  FTB  and  other  created  entities  to 
be  determined  by  DIS  interface.  Algorithm  to 
be  based  on  entity  type. 

Dead  Reckoning 
Algorithm 

Fixed  at  entity 
creation 

Enumerated  type.  Appendix  1.30.7 

4  [DRM  (R,V,W)] 

Linear  Accderatian 

X-oonqxmem 

Y-component 

Z-conqxnent 

Variable,  based  on 
instantaneous 
acceleration  at  time  of 
PDU 

Vector  in  Entity  Coordinates.  Each  componeru 
is  a  32-bit  floating  point  number,  conforming  to 
IEEE  754-1985.  Units  are  meters  per  second 
per  second. 

Derived  from  UDOTTF, 
VDOrTF.WDOTTFm 
program  AIRPLN 

Angular  velocity 

Rate  about  x-axis 
Rate  about  y-axis 
Rate  about  z-axis 

Variable,  based  on 
instarttaneous  angular 
velocity  at  time  of 

PDU 

Rate  at  which  entity’s  orientation  is  changing. 
Each  rate  is  a  32-bit  integer  in  units  of  BAM's 
per  millisecond,  relative  to  Emily  Coordinates. 
The  positive  direction  is  counter-clockwise 
about  eadi  axis. 

Derived  from  PB(R>YR. 
QBODYR,RBODYRin 
program  AIRPLN 

Other  parametcn 

TBD 

TOD 

n/a 

EndQ'  Appearance 

Variable,  depending 
on  state  of  enti^  at 
time  of  PDU. 

Bit  field  definitions  dqrendent  on  Entity  Kind 
and  Domain,  defined  in  Aj^rendix  D. 

Use  of  this  field  will  be 
determined  in  Phase  n. 

Entl^  Marking 

Special  markings  on  ITB  aircrafL 

Character  set 

Fixed  at  erttity 
aeation 

A{^)endix  F JO.  1.4 

1 

1*^  Character... 
ll^Chaiacter 

Fixed  at  entity 
creation,  possible 
modified. 

Siring  of  characters,  can  be  inierpreied  for 
di^ltor.  Most  significant  (first)  character  at 
start  of  string.  Unused  characters  set  to  blank. 

Capabilities 

Rxed  at  entity 
creation 

Bit  field  definitions,  defined  in  5.2.7 

0 

Nnmbcrof 

Ardcnlation 

Parameters 

Variable,  depending 
on  state  of  entiQr  at 
time  of  PDU 

Number  of  Articulation  Parameter  records  to 
follow. 

0 

Articiilation 

Parameters 

Rqteated,  actual 
mnhbermqr  vary 

DIS  interface  must  get  infotmation  from  ITB. 
DIS  interface  will  perform  dead  reckoning 
cakulations  associated  with  aiticulaied  parts. 

Change  indicator 

Variable 

Set  to  one  at  start,  mcremented  widi  each 
change  in  the  articulated  part 

n/a 
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Table  22.1-2  Transmit  PDU:  Entity  State  -  (ConUnued) 


Field 

Source 

Activity/Notes 

Source/Value 

ID-atuched  ID 

Rxed  at  entity 
cxeation 

Part  articulation  numba  index  of  entity/pait  to 
which  it  is  attached.  Zero  is  main  entity,  one  or 
higher  indicates  attachment  to  other  articiilated 
parL 

n/a 

Panmeicr  type 

Hxed  at  entity 

CTeatioo 

Definitions  in  Appendix  G,  quite  complicated. 
Some  types  indicate  pan  definition  and 
enumeration,  other  pan  definition,  enumeration 
and  type  of  dau  to  follow.  The  second 
variation  may  have  several  parammen  Qpes  to 
fiiUy  define  it. 

n/a 

Panmeier  value 

Variable,  depending 
on  state  of  entity  at 
time  of  PDU 

Dqiendeni  on  parameter  type,  64  bit  field. 

May  be  a  numeric  value,  enumeration  value  or 
an  entity  type.  Numeric  units  and  format 
depend  on  the  type  of  value  represented.  See 
Appendix  G. 

n/a 

611-91600Q2 


17 


Simulator  Networking  Final  Rei 


Table  22.1-3  Transmit  PDU:  Fire 


Field 

Source 

Activity/Notes 

Souixe/Value 

Protocol  VcrtiM 

Fixed 

Assigned  before  exercise 

mm 

Eurcitolilcaliflcr 

Fixed 

Assigned  before  exercise  (4.7. 1.2) 

mm 

PDU  Type 

Fixed 

Constant  2 

2 

nriog  Entity  ID 

Site 

Hom 

Entity 

Fixed 

See  Entity  Ideiuifier  for  Entity  State  PDU 

Same  as  Entity  State 
PDU 

Target  Entity  ID 

Site 

Host 

Entity 

Fixed  at  time  of  PDU 

All  zeroes  if  intended  targets  is  unknown.  See 
Entity  Identifier  for  Entity  State  PDU 

All  zeroes 

Munition  ID 

Site 

Host 

Entity 

Fixed  at  time  of  PDU 

All  zeros  mean  munition  not  represented  as 
separate  eittity  and  therefore  cannot  be  detected 
or  tracked.  Whether  the  munition  is  modeled 
explicitly  depends  on  the  sensing  capal^ties  of 
the  other  players  in  the  scenario.  This  should 
be  determined  before  the  starL  An  explicitly 
modeled  munition  requires  its  own  munition 
model  in  the  ITB  software.  See  Entity 
Identifier  for  EniiQ'  State  PDU. 

AH  zeroes 

Event  ID 

Assigned  by  DIS  interface. 

Site  Identifier 

Fixed 

... 

See  *'Site  Identifier”  from  Entity  Identifier  for 
Etuity  State  PDU 

mm 

Host  Identifier 

Fixed 

See  "Host  Identifier”  bom  Entity  Identifier  for 
Entity  State  PDU 

mm 

Event  Identifier 

Variable 

Used  to  link  Fire  PDU  to  Detonation  PDU. 
Event  sequences  use  a  common  event 
identifier.  The  event  identifier  starts  at  one  and 
is  incremented  at  the  start  of  each  sequence. 

A  sequential  counter  of 
releases  will  be  added  to 
routine  WEAFEX. 

Time  Stamp 

UTC  or  internal 
simulator  time 

See  Time  Stamp  for  Entity  State  PDU 

UTC  will  be  used  if  it  is 
installed. 

Location  in  World 

X-conqxment 

Y-oomponent 

Z-conqxment 

Variable,  based  on 
location  firom  which 
munitians  were 
launched 

Location  in  world  coordinates.  See  Entity 
Location  for  Entity  State  PDU.  It  is  an  of&et 
from  the  world  location  of  the  aircrafL 

Fixed  otfs€t  to  current 
aircraft  posidon,  offset  is 
TBD. 

Burst  Descriptor 

Other  simulators  use  this  to  produce  firing 
effects.  This  data  will  be  extracted  from  the 
wesqwn  model. 

Munition 

Fixed  at  time  of  PDU 

Entity  Type  record  with  enumerated  kind  set  to 
munition.  This  is  required  whether  or  not  the 
munition  is  represented  as  a  s^arate  enti^. 

Bnnbs  are  not  defined  in 
die  standard. 
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Table  22.1-3  Transmit PDU:  Fire  -(Continued) 


Field 

Source 

Activity/Notes 

Source/Value 

Wariwad 

Fixed  at  tune  of  PDU 

Enumerated  type.  Appendix  B30.1 

Selectable  by  ITB 
operator  at  start  of 
scenario. 

Fuze 

Fixed  at  time  of  PDU 

Enumerated  type.  Appendix  B30.1 

Selectable  by  1TB 
operator  at  start  of 
scenario 

Quantity 

Fixed  at  time  of  PDU 

Number  of  rounds  fired  m  this  burst,  16-bit 
unsigned  integer. 

See  Note  1  below 

Rate 

Fixed  at  time  of  PDU 

Rounds  per  minute  for  the  specified  munition. 
If  quantity  is  one,  rate  will  be  set  to  zero,  16-bit 
unsigned  integer. 

See  Note  1  below 

Velocity 

X-component 

Y-component 

Z-con^Jonent 

Instantaneous  velocity 
of  munition  at  time  of 
PDU 

Linear  velocity  of  munition  at  time  of  firing  in 
world  coordinated,  32-bit  floating  point 
conforming  to  IEEE  754-1 98S,  in  units  of 
meters  per  second.  It  is  derived  from  the 
velocity  of  the  aircraft 

Same  as  aircrafL 

Range 

Fixed  at  dme  of  PDU 

Range  in  meters  that  entity’s  fire  control 
system  assumes  in  computing  Hre  control 
solutioiL  Set  to  zero  if  unknown  or  unavailable 
32-bit  floating  point,  IEEE  754-1985,  in  units 
of  meters.  This  is  extracted  from  the  weapon 
model. 

From  trajectory 
calculations  in  routine 
TRAJEC. 

Note  1 :  The  MK-82  release  is  programmable  for  number  of  bombs  to  release  and  their 
expected  spacing  upon  impact.  This  is  dependent  on  the  aircraft  altitude,  orientation, 
and  velocity  at  the  time  of  release.  The  quantity  and  rate  will  be  calculated  based  horn 
these  values. 
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Table  2JJ-4  Transmit  PDU:  Detonation 


Field 

Source 

Activity/Notes 

SourccA^akic 

Pratoooi  Vcnkw 

Rxed 

Aaigned  before  exercise 

** 

EnrcteeUcntUlcr 

Fued 

Assigned  before  exemise  (4.7.1.2) 

mm 

PDU  Type 

Hxed 

ConstsntS 

3 

Ffarlag  Entity  ID 

Site 

Host 

Enii^ 

RxedattimeoflnK 

PDU 

Same  as  corresponding  Fire  PDU 

Same  as  Hre  PDU 

Target  Entity  ID 

Site 

Host 

Entity 

Fixed  at  time  of  File 
PDU 

Same  as  coresponding  Hre  PDU 

All  zeroes 

Munition  ID 

Site 

Host 

EntiQr 

Fixed  at  time  of  Hie 
PDU 

Same  as  corresponding  Fire  PDU 

All  zeroes 

Event  ID 

Site 

Holt 

Entity 

Fixed  at  time  of  Hre 
PDU 

Same  as  corresponding  Fire  PDU 

Same  as  Hre  PDU 

Tbnc  Stamp 

UTC  or  internal 
simulator  time  of 
detonation 

See  Time  Stamp  for  Entity  State  PDU  The 
weapon  model  must  return  the  time  of 
detonation. 

Calculated  by  routine 
TRAJEC.  UTCwillbe 
used  if  it  is  installed. 

Location  in  World 

X-oomponent 

Y-component 

Z-component 

Variable,  based  on 
location  where 
detonation  occurs 

Location  in  world  coordinates.  See  Entity 
Location  for  Entity  State  PDU.  This 
information  must  come  from  the  weapon 
model. 

Calculated  by  routine 
TRAJEC. 

Burst  Dcscriptm* 

Munition 

Warhead 

Fuze 

Quantity 

Rate 

Fixed  at  time  of  Hie 
PDU 

Same  as  corresponding  Fire  PDU. 

Same  as  Fire  PDU 

Velocity 

X-component 

Y'conqxment 

Z-conqxment 

Instantaneous  velod^ 
of  munition 
immediately  prior  to 
detonation 

Linear  velocity  of  munition  in  world 
coordinates,  32-bit  floating  point,  conforming 
to  IEEE  7S4-198S,  in  units  of  meters  per 
second.  This  information  must  come  from  the 
weqxMi  model 

Calculated  by  routine 
TRAJEC. 

Location  in  Entity 
Coordinates 

X-oomponent 

Y-oomponent 

Z-oomponmt 

Variable,  depending 
on  target  location 

Location  of  detonation  with  respect  to  the 
target,  in  the  target’s  entity  coordinates.  This 
field  will  be  zero  if  no  Target  Entity  ID  is 
specified.  This  is  determined  by  the  DIS 
interface. 

AH  zeroes 
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DctonatioB  Result 

Detennined  at  time  of 
PDU 

Enumerated  type.  Appendix  F.30.13,  from 
weapon  model  OcDetonate,  l^ln^Mct. 

Bomb  must  be  properly 
armed  by  pilot  to 
deumate. 

Number  of 

AiUcubtkm 

Parameters 

TBD 

Number  of  Articulation  Parameter  records  to 
follow,  not  clear  whether  weapon  model  or  DIS 
interface  would  determine  this. 

0 

Articulation 

Parameters 

TBD 

See  Articulation  Parameters  for  Entity  State 
PDU. 

n/a 

Change  indicator 
ID-altached  to 
Parameter  type 
Parameter  value 
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Table  2Jt.l-5  Transmit  PDV:  Collision 


FkU 

Source 

Activity/Notes 

Source/Value 

Pratoool  Venloa 

nxed 

Asigned  before  exercise 

ExcrciMldcBtiflcr 

Fixed 

Assigned  before  exercise  (4.7.1,2) 

PDUTjrpc 

Faed 

Constant  4 

4 

iMilng  Entity  ID 

Site 

Host 

End^ 

Fixed 

See  Evoit  Identifier  for  End^  State  PDU 

Same  as  Endty  State 

PDU 

Colliding  Entity  ID 

Site 

Host 

Entity 

Determined  by 
collision  detection 
algorithm 

Endty  Identifier  of  object  that  the  issuer 
collided  with,  zero  if  unknown  or  terrain.  If  a 
Collision  PDU  is  also  received  from  the 
colliding  oitity  or  collision  it  with  terrain, 
damage  to  ITB  must  be  computed. 

Calculated  by  ITB 
Collision  Evahiadcn 
task. 

Event  ID 

Site 

Host 

Enti^ 

Fixed  at  time  of  PDU 

See  End^  ID  of  Fire  PDU 

A  sequential  counter  of 
ooUiskmt  will  be 
maintained  by  the  ITB 
Cdllisicn  Evaluadon 
task. 

Time  Stamp 

UTC  or  intemal 
simulation  time  of 
collision 

See  Time  Stamp  for  End^r  State  PDU 

UTC  will  be  used  if  it  is 
installed. 

Veloci^ 

X-oomponent 

Y<omponent 

Z-cxMnponeiit 

Instantaneous  velocity 
of  issuer  at  time  of 
collision 

Linear  velocity  of  issuer  at  time  of  collision  in 
world  coordinates,  32-bit  floating  point, 
conforming  to  IEEE  754-198S,  in  uiuts  of 
metos  per  second 

Aircraft  velocity  at  time 
of  inqiicL 

Mas 

Instantaneous  mass  of 
issuer  at  time  of 
collision 

Mass  of  issuing  endty,  32-bit  floating  point, 
conforming  to  IEEE  754-1985,  in  uiuts  of 
kilograms 

Aircraft  mass  at  time  of 
impact,  includes  fuel, 
external  stores,  etc. 

Location  vrith  Respect 
to  Entity 

X-oomponent 

Y-oonq;)onent 

Z-component 

Variable,  depending 
on  target  location 

Location  of  collision  with  respect  to  the 
colliding  entity  in  the  colliding  entity’s 
coordinates.  This  field  will  be  zero  if  no 
colliding  EndQ'  ID  is  qiecified. 

Calculated  by  1TB 
Collision  Evaluadon 
task. 
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Table  22.1 Transmit  PDV:  Resupply  Cancel 


FieU 

Source 

Activfty/Notcs 

Source(Value 

Protocol  VmlM 

F»ed 

Assigned  before  exercise 

•• 

Eurcisc  UmlUlcr 

Fixed 

Assigned  before  exercise  (4.7.1.2) 

PDUTypt 

Rxed 

ConstsntS 

8 

RtqoMtiQg  Entity  ID 

Site 

Hoot 

Entity 

Rxed  u  time  of 

Service  Request  PDU 

Sme  ss  corresponding  Service  Request  PDU 

Entity  ID  verbatim  {ram 
Service  Request  PDU. 

Servicing  Entity  ID 

Site 

Host 

Entity 

Rxed 

See  Entity  Identifier  for  Entity  State  PDU 

Entity  ID  of  ITB. 

Table  22.1-7  Transmit  PDV:  Repair  Complete 


Field 

Source 

Activity/Notes 

Sourcc/Value 

Protocol  Version 

Fixed  at  start 

Assigned  before  exercise 

•• 

Exercise  Identifler 

Faed 

Assigned  before  exercise  (4.7. 1.2) 

•r* 

PDU  Type 

Rxed 

Constant  9 

9 

Reqnestliig  Entity  ID 

Site 

Host 

Entity 

Rxed  at  time  of 

Service  Request  PDU 

Same  as  corresponding  Service  Request  PDU 

Entity  ID  verbatim  fiom 
Service  Request  PDU. 

Servicing  Entity  ID 

Site 

Host 

Entity 

Fixed 

See  Entity  Identifier  for  Entity  State  PDU 

Entity  ID  of  1TB. 

Repair 

Fixed 

No  repairs  performed 

0 

222  Received  PDU’s 

The  received  PDU’s  have  direct  effect  over  the  fidelity  of  the  simulation  as  viewed  by  fire  pilot  of  the  ITB 
cockpit  The  critical  concerns  involve  taking  the  information  from  the  PDU’s  and  injecting  it  into  the 
fimctional  components  of  the  ITB  software  (sensors  models,  out-the-window  display  and  so  on)  in  a 
timely  manner.  Some  new  capabilities,  such  as  dead  reckoning  calculations,  will  need  to  be  added. 
Important  observatioiuil  tests  will  be  performed  during  Phase  II  when  the  ability  to  receive  PDU’s  has 
beffl  implemented.  There  have  been  SIMNET  problems  concerning  discrete  platform  jumps  assodated 
with  entity  state  data.  This  may  affect  displays  and  sensor  models.  It  could  have  a  great  effect  on 
coordinated  platform  movement  (such  as  formations)  as  well  as  aerial  combat  and  missile  evasion. 
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Analysis  of  the  received  PDU’s  is  summarized  in  the  following  t^l^.  Report  Section  and  i^qiendix 
references  in  the  tables  are  for  the  DlS-standards  document  “Protocol  Data  Units  for  Entity  Information 
and  Entity  Interaction  in  a  Distributed  Interactive  Simulation.  Table  2.2.2- 1  provides  a  cross-reference 
b^ween  PDU  figure  definitions  in  the  DIS-standards  document  and  the  tables  in  this  seoion. 


Table  2JJ-1  Receive  PDU  Figure/Table  Cross-R^erence 


PDU 

DlS-Staodards  Figure 

Table  Number 

Entity  State 

5-19 

2.2.2-2 

Fire 

5-20 

2.2.2-3 

Detonation 

5-21 

2.2.24 

Collision 

5-28 

2.2.2-5 

Service  Request 

5-22 

2.2.2-6 
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Table  2JJ-2  Receive  PDV:  Entity  Suue 


ndd 

Soarce 

Activity/Notes 

Uic/DatiiMiOB 

Pfolocol  Vintott 

Fixed 

Must  match  ITB  c^ialtiliQr. 

Error  if  no  match 

EmtcIm  IdmtMir 

Fixed 

Must  be  as  expected. 

Error  if  immaufa 

PDUTjrpt 

Fixed 

Constantl 

EatMgrlilaitiflcr 

Fields  uniquely  identify  each  entity.  TaUe  of 
entities  maintained  in  DIS  interface.  Must  be 
able  to  translate  u>  created  ITB  entries  for 
sensor,  weqxm.  displsy  functions. 

Create  new  entry  in 

Entity  Data  Structures  if 
first  appearance. 

Siteldentifiar 

Rxed 

Assigned  fay  authority  managing  DIS  exercises 

Mqr  affect  time  stamp 
mterpretation 

HoBtldouiSar 

Faed 

Assigned  by  autiiori^  managing  NS  exercises. 
One  site  may  have  several  hosts. 

Mqr  affect  time  stanq> 
mtetpretation 

Enti^  Identifier 

Fixed  at  entity 
aeation 

Eadi  enthy  created  by  host  has  its  own  unique 
entity  identifier. 

Forte  Identifier 

Fxed  at  entity 
creation 

Enumerated  type.  Appendix  E.30.1.1, 
infonnative. 

Infbnnatianal 

EatiqrTypc 

Defines  appearance  of  enti^  to  senson,  OTW 
display,  etc.  This  information  must  be  injected 
into  the  ITB.  DIS  interface  must  have 
knowledge  of  ITB  categorization  of  entities. 

Used  to  access  Eatify 
dtttbisc 

mries  aoceoed  by  k^. 

EntiqrKind 

Hxedatenti^ 

creation 

Enumerated  type.  Appendix  H130.1 

Pvt  of  key 

Domein 

Fixed  at  entity 
creation 

Enumerated  type,  value  depends  on  entity  kind. 
Appendix  HlJO.l  subsections 

May  aid  visual 
representation 

Country 

Fixed  at  entity 
creation 

Enumerated  type,  zero  for  environmental  and 
cultural  feature  entity  kind,  ^ipendix  F30.1.2 

Part  of  k^ 

Category 

Fixed  at  entity 
creation 

Enumerated  9pe 

Platfoim:  ^rpendix  H230.2 

Munition:  Appendix  H2303 

Life  Femu  ^)pendix  H130.13.3 
Environmental:  Appendix  HI  30.1 .4.3 
Cultural:  Appendix  H130.133 

Part  of  key 

Subceiegory 

Rxed  at  entity 
creation,  possibly 
modified  due  to 
attrition 

Enumerated  type,  (aJc.a.) 

Platform:  (Designation)  H2.30.2 

Munition:  (Designation)  H2303 

Life  Form:  (Designation)  HI  .30.1.3.3 
Environmental:  (Size) HI. 30. 1.4.3 

Cultural:  (Size)  Hl.30.13.3 

Part  of  key 

Specific 

Fixed  at  entity 
creation,  possibly 
modified  due  to 
attrition 

Enumerated  type,  (aJt.a.) 

Platform:  (Model)  H2303 

Munition:  (Model)  H2.303 

Life  Form:  (Number)  H130.133 
Environmental:  (Unused)  H130.1.43 
Cultural:  (Unused)  H130.13.3 

Part  of  key 

Extra 

Fxed  at  entity 
creation 

Not  used  for  any  entity  kind 
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Table  222-2  Receive  PDV:  Entity  State  -  (Continued) 


Fkld 

Source 

ActivHy/Notcs 

Uac/Dcstkuitiou 

Akcnult  Eallly  Tjpe 

Eatity  Kind 

Donuun 

Counay 

Categocy 

Subcaiegcxy 

Spacific 

&tra 

Rxad  at  entity 
creation,  poaaiUe 
modified  due  to 
attrition 

Same  formatt  as  Entity  Type,  puyose  it  that 
tome  players  may  have  ahemaiive  view  of  the 
entity.  Its  use  will  dqiend  on  the  requirementt 
of  olhen  in  the  simulation. 

WEI  not  be  used. 

Tfane  Stamp 

Univenal  Coordinated 
Time{UTC)or 
mtemal  aimulator 
(relative  time) 

Indicates  the  time  at  which  the  data  is  valid. 

Up  to  one  hour  can  be  rqtresented,  units  are 
36(X)A^*  seconds.  Bit  zero  it  0  if  relative,  1  if 
UTC.  See  S.2.19.  DIS  interface  will  update 
deal  reckoned  location  from  this  time  to  currem 
time. 

Used  in  dead  reckoning 

Eatity  Locadoa 

X-oonqxmott 

Y-conqxmem 

Z-componeat 

Variable,  based  on 
location  of  a  particular 
part  of  the  entity, 
represents  the  origin 
of  the  entity 
cooidiiuae  system 

Geocentric  Cartesian  Coordinatet  (World 
Coordinates)  origin  it  the  centroid  of  the  earth, 
positive  x-axis  passes  through  Prime  Meridian 
and  Equator,  positive  y-axit  dirough  E90*  and 
Equator,  positive  z-axis  through  Nordi  Pole. 

component  it  64-bit  floating  point, 
conforming  to  IEEE  754-1985.  Theshyeof 
earth  it  based  on  World  Geodetic  System  1984 
survey  (WGS-1984).  Units  ate  meters.  Mutt 
be  tnnslued  into  units  accepted  by  ITB. 

Used  in  dead  reckoning 
calculations. 

Entity  Linear  Velocity 

X-conqxment 

Y-oonqxment 

Z-conqxmeat 

Variable,  based  on 
instantaneous  velodcy 
attimeof  PDU 

Vector  relative  to  axes  used  to  rqtresem  the 
Entity  Location  (World  Coordinates).  Each 
component  is  a  32-bit  floating  point, 
conforming  to  IEEE  754-1985.  Units  are 
meters  per  second. 

Used  in  dead  recimning 
calculatians. 

Entity  Orientation 

Psi 

Theta 

Phi 

Variable,  based  on 
instantaneous 
orientation  at  time  of 
PDU 

Represents  transformation  from  Geocentric 
Cartesian  Coordinatet  to  Entity  Coordinates. 
Entity  Coordinates  origin  at,  the  center  of  the 
bounding  volume,  indqtendem  of  articulated 
parts.  Positive  x-axis  is  front,  positive  y-axis  is 
right,  positive  z-axis  is  down.  (Psi,  Theta,  Phi) 
rejsesent  standard  Euler  angles.  Units  are 
called  Bituiy  Angle  Measurement  (BAM) « 
360/2^  degrees.  Must  be  translated  into  unites 
accqxed  by  TTB. 

Used  in  dead  recktming 
calculatkms. 

Dead  Reckoning 
Parametera 

Dead  reckoning  is  performed  in  the  DIS 
interface.  The  conyuted  and  translated 
location  and  orientation  are  passed  to  the  ITB. 

Appendix  L30.6  listt 
fomulas  for  each  dead 
reckoning  algoridun. 

Dead  Reckcning 
Algorithm 

Inxed  at  entity 
creation 

Enumerated  type.  Appendix  L30.7 

Determines  ype  of  dead 
reckoning  algorithm  to 
use. 

linear  Accdendoa 

X-oonyonent 

Y-conyonent 

Z<oiiycnent 

Variable,  based  on 
instantaneotts 
acceleration  at  time  of 
PDU 

Vector  in  Entity  Coonhnaies.  Eadi  conyonent 
is  a  32-bit  floating  point  number,  conforming  to 
IEEE  754-1985.  Units  are  meters  per  second 
per  second. 

Used  in  dead  reckoning 
calculadoitt. 
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TaMe22J-2  RecdvePDV:  Entity  State  -  (Continued) 


FieU 

Source 

Activity/Notes 

Utte/DeitiuatiM 

AagubrvelDciiy 

Rate  about  x-uic 
Rate  about  y-axia 
Rate  about  z-axif 

VaritMe,  baaed  on 
inatanlaneoua  angulv 
velocity  at  time  of 

nxj 

Rate  at  which  entity'c  orientation  ia  changing. 
Each  rate  ia  a  32-bit  intqer  in  unite  of  RAM’s 
per  millisecond,  relative  to  Entity  Coordinates. 
The  positive  direction  is  counter-clodcwise 
about  eacb  axis. 

Used  in  dead  recknaii^ 

Other  panmaltn 

TBD 

TBD 

EattQr  AppcaruMa 

Variable,  depending 
on  atate  of  entity  at 
timeof  PDU. 

Bit  field  definitiona  depeadem  on  Entity  Kind 
and  Donain,  defined  in  Appendix  D.  Defines 
appearance  of  entity  to  sensors. 

May  be  used  in 
OTW/FliRdispIq«. 

Eatity  Marfclug 

Defines  ^jpearance  of  entity  to  sensors. 

Qiancttrfet 

Fixed  at  entity 
creation 

^tpendix  FJO.M 

I'^Qtaracter.. 

ll^Charactci 

Rxed  at  entity 
creation,  poaaible 
modified. 

String  of  characters,  can  be  interpreted  for 
diqtlqr.  Mott  significam  (first)  character  at 
start  of  string.  Unused  characters  set  to  blank. 

Informational,  not 
applicable  to  initial 

iiwpVithgaitmttfi 

Capabllltlea 

Rxed  at  entity 
creation 

Bit  field  definitions,  defined  in  S.2.7,  implicit 
knowledge  of  cqiebility  of  odiers. 

Number  or 

Parameten 

Variable,  depending 
on  attte  of  entity  at 
timeof  PDU 

Ntanber  of  Articulation  Parameter  records  to 
follow. 

Wni  not  be  used  in 

initial  nnplnmintfliint 

ArtkulatiOB 

Panmetera 

Repeated,  actual 
number  may  vary 

DIS  interface  mutt  have  knowledge  of  the 
rrpresentation  capabilitiet  td  the  ITB  for  each 
type  of  entity.  Daiamustbeiraivlatedto 
omform  to  FTB  representation. 

Change  indicator 

Variable 

Set  to  one  at  start,  incremented  with  each 
diange  in  the  articulated  part 

ID-anached  to 

Fixed  at  entity 
creation 

Part  articulation  number  index  of  entity/part  to 
which  it  is  attached,  Zero  is  main  entity,  one  or 
higher  indicates  attadunentio  odier  articulated 
part 

Parameter  type 

Rxed  at  entity 
aeatkm 

Definitions  in  Appendix  G,  quite  complicated. 
Some  types  indicate  part  definition  and 
enumeradcit  other  part  definitkm,  enumeration 
and  type  of  date  to  follow.  'The  second 
variation  may  have  several  parameters  types  to 
fully  define  it 

Parameter  vahte 

Variable,  depending 
on  state  of  entity  at 
timeof  PDU 

Dependent  on  parameter  type,  64  bit  field. 

May  be  a  numeric  value,  enumeration  value  or 
an  entity  type.  Numeric  units  and  format 
depend  on  the  type  of  value  rqrtesented.  See 
Appendix  G. 
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TabU2J2J-3  Receive  PDU:  Fire 


Fidd 

Source 

Activity/Notes 

IWDcstiBatkNi 

Pralocoi  VviliMi 

Rxed 

Must  match  ITB  capebiliiy. 

Error  if  no  match. 

Eiarciw  MnMfiv 

Food 

Must  be  as  expected. 

Error  if  no  match. 

roUTypt 

Rxed 

Constant2 

FIrtagEatttylD 

Site 

Hom 

Enti^ 

Hxed 

See  Entity  Identifier  for  Entity  State  PDU.  Can 
be  used  to  create  effects  such  as  muzzle  flash. 

Error  if  Ftring  entity  not 
in  Entity  Dau  SDuctures 

TatfitEalttylD 

Site 

Host 

EntiQf 

Fixed  at  tune  of  PDU 

All  zeroes  if  intended  targets  is  imknown.  See 
Entity  Identifier  for  Entity  State  PDU. 

bifimnative 

MaaltloalD 

Site 

Host 

Eiiti9 

Hxed  at  time  of  roU 

All  zeros  mean  munition  not  represented  as 
sqjarate  entity  and  dicrefoie  cannot  be  detected 
or  tracked.  See  Entity  Identifier  for  Entity 
State  PDU.  Non  zero  value  means  new  entity 
for  munitian  must  be  created. 

Create  new  entity  in 
Entity  Data  Structures  if 
first  qrpearance. 

Event  ID 

Information  maintained  in  DIS  inicrface. 

Save  Firing  Entity 
Munition  ID. 

Site  Idiaitifig 

Fixed 

See  *^ite  Identifier**  fiom  Enti^  Identifier  for 
Entity  Stale  PDU. 

Host  Identifier 

Fixed 

See  **Host  Identifier**  firom  Enti^  Identifier  for 
Entity  Stale  PDU. 

Evem  Identifier 

Variable 

Used  to  link  Fire  PDU  to  Detonation  PDU. 
Event  sequences  use  a  common  event 
identifier.  The  event  identifier  starts  at  one  and 
is  incremented  at  the  start  of  each  sequence. 

Remove  munition  on 
detonation. 

Time  Stamp 

UTC  or  inieiiul 
nmulaior  time 

See  Time  Stanqr  for  Enti^  Slate  PDU 

biformational 

Locetioa  la  World 

X-oonqxment 

Y-component 

Z-composiBiit 

Variable,  based  on 
location  firom  which 
muniikms  were 
launched 

Location  in  world  coordinates.  See  Entity 
Location  for  Entity  State  PDU.  Represents 
where  munitions  were  launched,  not  centroid  of 
filing  entity. 

Used  in  dead  reckoning. 
This  can  be  used  to 
locate  firing  effects. 

Bant  Descriptor 

Used  to  aeate  firing  effecu  in  ITB. 

Informative  in  initial 
inqrlementatioB. 

Munition 

Rxed  at  time  of  firing 

Entity  Type  record  with  enumerated  kind  set  to 
muitition.  This  is  required  whetiier  or  not  die 
munition  is  represented  as  a  separate  entity. 

Wariiead 

Rxed  at  time  of  firing 

Enumerated  type,  ^rpendix  B30.1 

Fuze 

Fixed  at  time  of  firing 

Enumerated  type,  ^ipendix  B  JO.l 

Quantity 

Rxed  at  time  of  firing 

Number  of  rounds  fired  in  this  burst,  16-bit 
unsigned  integer. 
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Table  2JJl~3  Receive  FDV:  Fire  -  (Continued) 


FieU 

Source 

Activity/Notes 

Usc/DcstnatkM 

Rate 

Pued  at  time  of  firing 

Rounds  per  minute  for  the  specified  numition. 
If  quantiQr  is  one.  rate  will  be  set  to  zero.  16-bit 
unsigned  integer. 

Vdoclly 

X-omtqxment 

Y-conqwneat 

Z-coniponent 

Inaiantaneoua  velocity 
of  munition  at  time  of 
PDU 

Linear  velocity  of  munition  at  time  of  firing  in 
world  coordinates,  32-bit  floating  point 
conforming  to  IEEE  7S4-1985,  in  units  of 
meters  per  second. 

Used  in  dead  reduMiing. 

Range 

Hxed  at  time  of  firing 

Range  in  meters  that  entity’s  fire  control 
system  assumes  in  computing  fire  control 
solufion.  Set  to  zero  if  unknown  or  unavailaUe 
32-bit  floating  poiiu,  IEEE  7S4-198S,  in  units 
of  meters.  This  is  extracted  from  the  weqton 
model. 

Informative 

Tabu  2JJ-4  Receive  PDU:  Detonation 


Fidd 

Source 

Activity/Notes 

llse/Dcstyurtiou 

Protoeol  VmtM 

Fued 

Must  match  ITB  capability. 

Error  if  no  match. 

EnrdM  UeiitlflB- 

Fixed 

Must  be  as  expected. 

Encr  if  iw  match. 

pduttp* 

Fixed 

ConstaiuS 

FIriBg  EDtitjr  D) 

Site 

Hom 

Entiiy 

Fixed  at  time  of  Hk 
PDU 

Same  as  corresponding  Fire  PDU 

Error  if  no  match  with 
Event  ID  Fring  Entity. 

Tugtt  Entity  ID 

Site 

Host 

Entity 

Fxed  at  tune  of  Fire 
PDU 

Same  as  corresponding  Fire  PDU 

biformative 

Munition  ID 

Site 

Host 

Entity 

Fixed  at  time  of  Hre 
PDU 

Same  as  corresponding  Fire  PDU 

Terminate  Munition 

Entity 

Event  ID 

Site 

Host 

Event 

Fixed  at  time  of  Fire 
PDU 

Same  as  corresponding  Fire  PDU 

Error  if  original  Event 

ID  not  received. 

Time  Stump 

UTC  or  internal 
simulator  time  of 
detonation 

See  Time  Stamp  for  Entity  State  PDU  To 
accurately  determine  damage,  must  know 
where  ITB  is  at  this  time.  This  is  absolutely 
necessary  for  collateral  damage. 

Compare  to  1TB  location 
at  time  to  determine 
datiuge. 

Locution  in  World 

X-oonqxMwnt 

Y-component 

Z-conyonent 

Variable,  based  on 
location  where 
detonation  occurs 

Location  in  world  coordinates.  See  Entiiy 
Location  for  Entity  State  PDU. 

Compare  to  TIB  location 
at  time  to  determine 
damage,  used  in 
Deumadon  Assessment 
task. 

Burst  Dexilptor 

Munition 

Waiheed 

Fuze 

Quantity 

Rate 

Fixed  at  time  of  Fire 
PDU 

Same  as  corresponding  Fire  PDU.  Used  in 
damage  determination. 

Factors  in  damage 
assessment 

Velocity 

X-oomponent 

Y-oon^oiMtt 

Z^on^onent 

Instantaneous  velocity 
of  munition 
uiunediately  prior  to 
detonation 

Linear  velocity  of  munition  in  world 
coordinates,  32-lnt  floating  point,  conforming 
to  IEEE  7S4-198S,  in  units  of  meters  per 
second. 

Factors  in  damage 
assessment  used  in 
Detonation  Assessment 
task. 

Locution  in  Entity 
Coordinuteu 

X*conipoiicnt 

Y-ooniponent 

Z'<ofnpoiiB]it 

VariaUe,  depending 
on  target  location 

Location  of  detonation  with  respect  to  the 
target,  in  the  target’s  entity  coordinates.  This 
field  will  be  zero  if  no  Target  Entity  ID  is 
spedfied.  Important  if  ITB  is  the  target  entity. 

Alternative  to  conqmting 
ITB  location  at  time  of 
detonatkm,  used  in 
Detonation  Assessment 
task  if  availalde. 
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Table  222-4  Receive  PDV:  Detonation  -  (Continue) 


DdoudM  Remit 

Determined  at  time  of 
PDU 

Enumerated  type.  Appendix  F30.1  J.  There 
must  be  a  function  in  the  ITB  to  compute 
damage  based  on  location  of  detonation, 
location  of  ITB,  burst  descriptor  (including 
munition  ID),  velocity  of  munition,  and 
detonation  lesulL  The  fiatetion  may  cause  ITB 
c^tability  and  q>pearance  to  change. 

Indication  of  in^Mct  or 
detonation,  affects 
damage  assessment,  used 
in  Detonation 

Assessment  task. 

Nimbcrcf 

Articolatloa 

PiruMten 

TBD 

Number  of  Articulation  Parameter  records  to 
follow. 

HJA  until  ITB  has 
articulated  paiu. 

AiHoilatloa 

PmnuMten 

TBD 

See  Articulation  Parameters  for  Entity  State 
PDU. 

Change  indicator 
ID-anached  to 
Parameter  type 
Parameter  vahie 
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Table  222-5  Receive  PDV:  Collision 


Field 

Source 

Activity/Notes 

Use/DestmatioB 

Protocol  VtnIoB 

Faed 

Must  match  ITB  capability. 

Error  if  no  maidi 

Excrciic  Identifier 

Fued 

Must  be  as  expected. 

Error  if  no  match 

PDUTTpe 

Fued 

Constant  4 

laming  EotiQ' ID 

Site 

Host 

Entity 

Fued 

See  Entity  Identifier  for  EndQr  State  PDU. 

Error  if  issuing  entity  not 
in  Entity  Dau  Structure. 

CoDidtiig  Entity  ID 

Site 

Host 

Entity 

Determined  by 
collision  detection 
algorithm 

Entity  Identifier  of  object  that  the  issuer 
collided  with,  zero  if  unknown  or  terrain. 
Important  if  this  is  FTB  cockpit  and  ITB  has 
also  determined  that  coUisbn  occurred.  In  this 
case,  a  damage  fimetion  must  be  added  to  ITB, 
and  it  may  cause  ITB  capability  and 
^ipearance  to  change. 

Ignore  unless  Entity  ID 
ofITB 

Event  ID 

Site 

Host 

Event 

Fixed  at  time  of  n)U 

See  Event  ID  of  Fire  PDU 

Informative 

Time  Stamp 

UTC  or  intemal 
simulatian  time  of 
collision 

See  Time  Stamp  for  EntiQ'  State  PDU 

For  collision  to  occur, 
mutual  determinatioa 
within  TBD  seconds. 

VekKi^ 

X-conqwnent 

Y-conqxment 

Z-oomponent 

Instantaneous  veloci^ 
of  issuer  at  time  of 
collision 

Linear  velocity  of  issuer  at  time  of  collision  in 
world  coordinates,  32-bit  floating  point, 
conforming  to  IEEE  754-1985,  in  units  of 
meten  per  second 

Factor  in  damage 
assessment,  used  in 
Collision  Assessment 
task. 

Mass 

Instantaneous  mass  of 
issuer  at  time  of 
collision 

Mass  of  issuing  entity,  32-bit  floating  point, 
conforming  to  IEEE  754-1985,  in  units  of 
kilograms 

Factor  in  damage 
assessment,  used  in 
Collision  Assessment 
ta.sk. 

Location  with  Respect 
to  Entity 

X-coroponent 

Y-companent 

Z-con^oneiit 

Variable,  depending 
on  target  location 

Location  of  collision  with  respect  to  the 
colliding  entity  in  the  colliding  entity’s 
coordinates.  This  field  will  be  zero  if  no 
colliding  Entity  ID  is  specified.  This  data  will 
help  to  determine  damage. 

Factor  in  damage 
assessment,  used  in 
Collision  Assessment 
task. 
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Table  2J22*6  Receive  PDV:  Service  Request 


Field 

Source 

Activity/Notes 

Protocol  Version 

Fixed 

Must  match  FTB  Mobility. 

Exercise  Identifier 

Fixed 

Must  be  as  expected 

PDU  Type 

Fixed 

Constants 

Requesting  Entity  ID 

Site 

Host 

End^ 

Fixed 

See  EntiQr  Identifier  for  Entity  State  PDU 

Servicing  Entity  ID 

Site 

Host 

Entity 

Fixed  at  time  of 
service  request 

Entity  that  provides  resupply  or  repair 

Service  Type 

Fixed  at  time  of  PDU 

Enumerated  Type,  Appendix  F.30.1.9 

Number  of  Supply 
Types 

Fixed  at  time  of  PDU 

Number  of  Supply  Quantity  fields  to  follow 

Supply  Quantity 

Entity  Kind 

Domain 

Country 

Category 

Subcaiegoiy 

Specific 

Extra 

Quantity 

Fixed  at  time  of  PDU 

Defined  in  5.Z17 

Use/Desliiuition 


Error  if  no  nutch 


Error  if  no  match 


Error  if  entity  not  in 
Entity  Dau  Structures. 
This  entity  wOl  receive 
the  repair/resupply 
response 


IfITB  specified,  must 
send  immediate  response 


rTB  Response:  If  1,  then 
Resupply  Cancel  PDU,  if 
2  then  Rqiair  Complete 
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2J  Performance  and  Interface  Requirements 

The  peifoimance  and  interface  requirements  for  adding  DIS  capability  to  the  ITB  are  given  in  this  sectimi. 
They  are  classified  as  follows: 

•  External  device  interface  requirements 

•  DIS/TTB  data  interchange  requirements 

•  Task  performance  requirements 

2  J.l  External  Device  Interface  Requirements 

Access  to  external  devices  is  required  in  order  to  verify  DIS-compliance,  to  connect  to  other  DIS  sites  and 
also  to  use  Universal  Gx)rdinat^  Time.  The  requirements  for  the  interface  are  given  in  this  sectirm. 

2J.1.1  Interface  to  Verify  DIS  Compliance 

Automated  Forces  Testbed  software  will  be  used  to  verify  DIS-compliance  in  the  ITB.  The  software  is 
available  at  no  cost  from  the  Institute  for  Simulation  and  Training  GST)  and  will  be  executed  on  an  IBM 
PC-oompadble  computer.  The  minimum  hardware  configuration  for  executing  the  Automated  Forces 
Testbed  software  is  as  follows. 

•  IBM-compatible  PC,  with  the  following  processor 

•  Intel  486  processor 

-  Intel  386  processor  with  floating  point  co-processor 

•  4  Megabytes  memory 

•  300  Megabyte  hard  disk 

•  3-Com  Etherlink-2  card 

WL/AAAS-2,  the  managers  of  the  ITB,  will  supply  all  of  the  hardware  except  for  the  disk  drive  to 
support  DIS-compliance  testing.  The  disk  drive  wUl  be  purchased  by  Amherst  Systems  and  ddivered  to 
the  government  during  Phase  II.  The  Ethernet  connector  of  the  PC  executing  the  Automated  Forces 
Testbed  software  will  plug  directly  into  the  Ethernet  link  from  the  Alliant  computer  running  the  ITB 
software.  This  is  illustrated  in  Figure  2.3.1. 1-1.  The  Ethernet  link  wiU  use  the  UDP/IP  GJser  Datagram 
Protocol/Intemet  Protocol)  to  exchange  information. 


AOVTECH.OCII4e74t2«« 


Figure  23.1.1 -I  Configuration  to  Verify  DIS-CompUance  of  ITB 
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23.12  Connection  to  Other  DIS  Sites 

For  Phase  n,  Amherst  Systems  has  proposed  perform  DIS  testing  with  the  Flight  Dynamics  Directorate  at 
Wrigbt-Panerson  AFB  and  also  with  off-based  simulators  to  be  determined  at  a  later  date.  Rgure  2.3.12- 
1  illustrates  the  on-base  network  at  Wright-Patterson  AFB  diat  will  suppon  the  tests.  There  are  bulk  fiber 
optic  caUes  that  run  between  the  Air  Force  Institute  of  Technology  (AFTT)  and  Building  620,  and  also 
between  Building  620  and  the  Flight  Dynamics  Directorate.  Individual  fiber  lines  will  be  dedicated  to 
connect  the  sites.  AFTT  and  the  Flight  Dyruunics  Directorate  intend  to  establish  a  cormection  within 
Building  620  that  bypasses  the  ITB,  which  will  give  the  Flight  Dynamics  Directorate  independent  DIS 
ctq)ability.  Although  the  fiber  link  exists  between  AFTT  and  Building  620,  the  local  area  networks 
(LAN’s)  remain  disconnected.  To  establish  connectivity  between  Building  620  and  AFTT,  Amherst 
System  has  offered  to  procure  and  deliver  to  the  government  two  fiber  optics  transceivers  as  pan  of  the 
Phase  n  effon.  The  early  procurement  of  these  items  will  permit  debugging  of  die  interface  software  to 
be  developed  under  this  task.  Installation  of  the  fiber  optics  transceivers  also  gains  access  to  the  T-1 
(Defense  Simulator  Internet)  long  haul  network.  T-1  lures  are  often  used  for  DIS  testing.  The  T-1  access 
is  essential  for  the  testing  with  off-base  simulators  as  discussed  in  the  Phase  U  proposal. 


Stwdatf  cpmpomntf  MfcK*  tom  to  te  prpcurttf  amr  dWfMntf  bf 
Am  Atnt  Systni*  to  wpporf  Hw  Aim*  fprpi^  T)»  o0Nr  oonyMnwKt 
an  ttMdy  Insulin)  er  will  t0ptnhiamlmptnitl)r. 

SMNET«Ca«l»Wta« 


Figure  23.12-1  Links  at  Wright-Patterson  AFB 
2  Use  of  Universal  Coordinated  Time  (UTC) 

Although  the  ITB  presently  uses  only  its  computer  processor  clock,  the  importance  of  using  Universal 
Coordinated  Time  (UTC)  for  DIS  applications  is  well  understood.  UTC  requires  access  to  GPS  signals. 
Fortunately,  UTC  capability  has  been  implemented  in  the  Integrated  Electromagnetic  Simulator  System 
(lESS),  which  is  located  in  a  vault  within  the  ITB  facility.  The  GPS  reception  antenna  and  its  wiring  are 
already  in  place  in  Building  620.  Use  of  UTC  will  require  access  to  the  GPS  signal,  purchase  of  a 
receiver  module,  integration  of  the  receiver  module  into  the  Alliant  computer  multiprocessor  system,  and 
developmem  of  software  to  interpret  and  ^ply  the  time.  WL/AAAS-2  is  investigating  the  acquisition  and 
installation  of  equipment  to  support  UTC.  Manufacturers  such  as  Odetics  and  Datum  sell  aiq>ropriate 
modules.  Should  this  equipment  be  purchased  and  installed,  Amherst  Systems  will  be  responsible  for 
developing  software  to  exploit  the  capability  during  Phase  II  of  this  project. 
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DIS/TTB  Data  Interchange  Requirements 


There  are  two  areas  of  interest  in  the  exchange  of  information  between  DIS  and  the  ITS.  The  first 
concerns  the  efficirat  processing  of  PDU’s  and  management  of  the  interface  to  other  simulator  sites.  The 
second  involves  the  managemoit  of  information  requited  to  support  the  DIS  interface.  Eadi  is  discussed 
in  the  following  paragraph. 

Management  of  DIS  Interface 

The  Ethernet  irtterface  used  to  exchange  PDU’s  with  other  simulators  must  be  managed  efficiently  in 
order  to  minimize  late  ies  and  distortions  in  the  simulation.  Outgoing  PDU’s  must  be  transmitted  as 
soon  as  possible  after  they  are  generated.  Incoming  PDU’s  must  be  processed  as  quickly  as  possible 
wlren  they  are  received.  To  accomplish  efficient  processing  of  PDU’s,  queues  will  be  established  to  hold 
the  PDU’s. 

2J  J.1.1  Incoming  PDU’s 

Receipt  of  a  PDU  wOl  trigger  interrupt  driven  processing  in  the  Ethernet  input  routine.  The  irqnit  routine 
will  place  the  PDU  at  the  end  of  Unprocessed  Input  PDU  Queue.  It  will  then  start  a  task  whose  purpose  is 
to  process  the  PDU’s  and  distribute  information  to  the  i^jpropriate  FTB  software  modules.  This  task  will 
continue  to  execute  as  long  as  there  are  unprocessed  PDU’s  queued.  Figure  2.3.2. 1.1-1  illustrates  die 
processing  and  Figure  2.3.2. 1.1 -2  provides  pseudo-code  for  the  processing.  Even  though  Figure 
2.3.2.1.1-1  shows  a  large  number  of  PDU’s  queued,  it  is  expected  that  the  queue  will  be  empty  most  of 
the  time  for  small  and  moderate  sized  scenarios. 


ETHERNET 

INPUT 

ROUTINE 


TO  ITB 
FUNCTIONS 


UNPROCESSED 
INPUT 
PDU  QUEUE 
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Figure  232.1.1  -1  Management  of  Incoming  PDU’s 
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ETHERNET  INPUT  ROUTINE 

PDU  PROCESSING  TASK 

Begin 

Begin 

Add  PDU  to  Queue; 

Loop 

Start  PDU  Processing  Task; 

K  No  PDU  Queued  Then 

End; 

Wait  to  be  Started; 

(Note:  This  routine  is  started  automatically 
when  a  PDU  is  received) 

EndK; 

Get  Next  PDU; 

Process  PDU; 

End  Loop; 

End; 

ADVTECH-DCR-206-082G92 


Figure  23Jld.l  -2  Pseudo-code  for  Processing  Incoming  PDU*s 
233.13  Outgoing  PDU’s 

PDU’s  can  be  generated  by  a  number  of  independently  executing  ITB  tasks.  There  are  two  problems  that 
can  result  The  first  is  diat  PDU’s  may  be  geirerated  simultaneously  by  the  tasks,  but  must  te  transmitted 
serially  by  the  interface.  The  second  is  that  the  interface  may  be  busy  and  not  able  to  accept  outgoing 
messages  for  a  period  of  time. 

To  solve  the  first  problem,  the  outgoing  PDU’s  will  be  queued  in  the  Ui^rocessed  Ouq>ut  PDU  Queue 
until  the  ouqjut  task  is  ready  to  accept  them.  Whoi  an  ITB  software  module  generates  a  PDU,  the  PDU 
will  be  appended  to  a  list  of  all  outgoing  PDU’s  awaiting  transmission.  Computer  system  interiock 
operations  will  be  used  to  prevent  conflict  in  case  two  or  more  PDU’s  are  added  at  the  same  time. 

To  ensure  that  the  queued  PDU’s  are  transmitted  as  quickly  as  possible,  an  Ethernet  Output  Task  will  be 
used.  The  will  take  a  PDU  from  the  queue  and  write  it  to  the  EfoemeL  The  Ethernet  Output  Task  will  be 
started  by  the  tasks  that  generate  PDU’s  and  will  continue  to  execute  as  long  as  there  are  uiq)rocessed 
PDU’s  queued. 

Figure  2.3.2.1.2-1  illustrates  the  processing  and  Figure  2.3.2.1.2-2  provides  pseudo-code  for  the  tasks. 
Even  thou|^  Figure  2.3.2.1.2-1  shows  several  PDU’s  queued,  it  is  expected  that  the  queue  will  be  empty 
most  of  the  time. 
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Figure  232.1J2-1  Management  of  Outgoing  PDU*s 


611-9160002 


Simulator  Networking  Final  Rt 


eport 


PDU  GENERATION 

ETHERNET  OUTPUT  TASK 

Begin 

• 

Loop 

• 

If  No  PDU  Queued  Then 

Gmerate  PDU; 

Whit  to  Be  Started; 

Add  PDU  to  Queue; 

EndK; 

Start  Ethernet  Output  Task; 

Get  Next  PDU; 

• 

Write  PDU  to  Ethernet; 

e 

e 

End  Loop; 

End; 

ADVTECH-0CR-20»O8268e 


Figure  2JJJJ-2  Pseudo-code  for  Processing  Outgoing  PDV*s 

2  J  J  J  Management  of  DTS  Data 

Information  from  the  incoming  DIS  PDU’s  must  be  assimilated  into  the  ITB  [»Dcessing.  Similarly, 
information  about  the  activity  of  the  ITB  simulated  aircraft  must  be  put  into  DIS  formats  for  transmission 
to  the  other  simulator  sites.  The  requirements  for  this  processing  are  discussed  in  this  section. 

2  J.2.2.1  New  ITB  Data  Stnictures 

To  support  the  new  ftmctionality  required  by  DIS,  several  new  data  structures  will  be  added  to  the  ITB 
software.  They  are  as  follows: 

•  Entity  Data  Structure 

•  Ordnance  Detonation  Queue 

•  Collision  Damage  Queue 


Entity  Data  Structure 

The  EntiQr  Data  Structure  will  be  a  list  of  Entity  Records,  indexed  by  Entity  Identifler  from  the  Entity 
State  PDU.  Each  Record  will  contain  movement  and  ^pearance  information  about  the  entity.  Figure 
2.3.2.2.1.1-1  illustrates  the  layout  of  an  &itity  Record. 
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Uniquely  identifies  each  entity 

Will  support  dead  reckoning,  information 
will  be  used  by  OTW  and  FUR  display, 
includes  current  position  and  orientation 


From  Entity  State  PDU 


Information  from  Coll^on  PDU,  including 
location,  relative  orientation,  time 


Time  that  ITB  determined  a  collision  occurred 


information  for  OTW  and  FUR  displays,  such 
as  display  icon  number,  also  indu^  collision 
data  such  as  dimensions  of  entity 

ADVTECH-DCR-21 0062702 


Figure  2JJJ.I.I -J  Layout  of  Entity  Record 

The  Entity  Data  Structure  will  be  accessed  for  the  following  reasons: 

a.  Receipt  of  Entity  State  PDU.  When  an  Entity  State  PDU  is  received,  a  new  Entity 
Record  will  be  created  if  one  does  not  yet  exist.  If  a  new  Entity  Record  is  created, 
other  Entity  Information  will  be  taken  from  the  Entity  Database  (see  Section  2.4.2.2). 
Entity  Movement  Information  and  &itity  Appearance  Information  will  be  copied  from 
the  ^tity  State  PDU.  Dead  Reckoning  cdculations  will  be  performed  to  bring  the 
entity’s  position  and  orientation  up  to  the  current  time. 

b.  Dead  Reckoning  Update.  During  a  dead  reckoning  update,  each  Entity  Record  will 
accessed  to  update  the  entity’s  position  and  orientation  to  reflea  the  current  time, 
of  the  information  required  to  perform  dead  reckoning  updates  will  be  kept  in 
EntiQ'  Record. 

c.  OTW/FLIR  Update.  During  an  OTW/FLIR  update,  each  Entity  Record  will 
examined.  If  an  entity  is  within  display  range,  the  entity’s  position  and  orientation, 
appearance  and  its  icon  number  will  be  used  to  construct  a  message  for  the 
OTW/FLIR  display. 
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d.  Receipt  of  Collision  PDU.  When  a  Qdlisioa  PDU  invcdving  the  ITB  is  received,  the 
time  of  the  ITB  Deteimined  Collision  Data  will  be  examined.  If  the  time  is  close,  then 
a  ocdlision  will  be  deemed  to  have  occuned  and  an  emiy  will  be  placed  on  the 
Collision  Damage  Queue.  If  there  is  no  time  match,  then  a  potential  collision  has 
occuimL  To  retain  this  infonnaticm.  pmendal  collisions  received  dirough  DIS  PDU’s 
will  be  retained  in  the  DIS  Deteimined  Collision  Data.  The  Entity  Record  will  contain 
information  from  the  FT>1}  including  the  timestamp.  Periodically,  the  ITB  software 
will  remove  data  which  are  obsol^  and  vrere  not  confirmed  by  the  ITB.  Dau  will 
also  be  removed  if  the  collision  is  confiimed  by  the  1TB. 

e.  ITB  CoUisitm  Evaluatitm.  Periodically,  the  1TB  will  check  to  see  if  it  has  collided 
with  another  entity.  If  the  ITB  calculates  that  a  collision  has  occurred,  the  DIS 
Deteimined  Collisitm  Data  will  be  examined  for  a  collision  involving  the  other  entity. 

If  the  times  are  dose,  then  a  collision  will  be  deemed  to  have  occurred  and  an  entiy 
will  be  |daced  on  the  Collision  Damage  Queue.  If  there  is  no  time  match,  then  a 
potential  collision  has  occurred.  To  retain  this  information,  the  time  of  the  potential 
collision  computed  by  the  ITB  will  be  retained  in  the  ITB  Determined  Collision  Data. 
Periodically,  the  ITB  software  will  remove  data  which  are  obsolete  and  were  not 
confirmed  by  DIS.  Data  will  also  be  removed  if  die  collision  is  confiimed  by  DIS. 

23J12A.2  Ordnance  Detonation  Queue 

When  a  Detonation  n>U  is  received,  its  infoimatitni  will  be  placed  in  the  Ordnance  Detonation  Queue.  A 
Detonation  Evaluatitm  task  will  remove  entries  from  this  queue  and  determine  the  damage  to  the  ITB,  if 
any,  caused  by  die  detonadoa 

Collision  Damage  Queue 

According  to  the  DIS  standard,  a  collision  between  entities  must  be  confiimed  by  bodi  entities  involved  in 
the  collisioiL  When  both  the  ITB  and  another  DIS  entity  have  deteimined  that  a  collision  between  them 
has  occuned,  information  ftom  the  Collision  PDU  will  be  placed  in  the  Collision  Damage  Queue.  A 
Collision  Evaluation  task  will  remove  entries  from  this  queue  and  determine  the  damage  to  die  ITB,  if 
any,  caused  by  the  collision. 

23J122  Processing  of  Incoming  Information 

Information  fiom  the  incoming  PDU's  provides  the  ITB  with  data  about  the  other  players  in  the 
simulation.  The  following  types  of  information  are  present  in  the  incoming  DIS  PDU’s. 

•  Entity  ai^iearance 

•  Entity  movement 

•  Werqxm  firing 

•  Ordnance  detonation 

•  Collisions 

•  Repair  and  resupply  requests 
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Entity  appearance  and  entity  movement  informaticm  will  be  placed  in  the  Entity  Data  Stnictuie  by  the 
PDU  Processing  Task.  Entity  appearance  will  be  reflected  in  the  OTW  Display.  Entity  movement 
information  is  used  to  compute  the  position  aixl  orientation  of  the  other  DIS  entities.  Weapon  flriQg 
information  will  be  noted  but  no  special  activity  wiU  result.  Ordnance  detonation  will  cause  the 
Detcmation  Evaluation  Task  to  execute  in  order  to  determine  effects  on  the  ITB.  Collision  information 
received  in  PDU’s  will  be  used  to  determine  damage  should  the  ITB  coiKur  that  a  coUisitm  has  occurred. 
Repair  and  resupply  requests  will  cause  the  PDU  Processing  Task  to  goierate  K>U  respcmses  denyirrg  the 
capability. 

23JL23  Processing  of  Outgoing  Information 

Information  for  outgoing  PDU’s  provides  other  DIS  entities  data  about  the  activity  of  the  ITB.  The 
following  types  of  mformation  are  present  in  the  outgoing  PDU's. 

•  ITB  appearance 

•  ITB  movement 

•  Release  of  ordnance 

•  Ordnance  detonation 

•  Collisions 

ITB  appearance  may  change  due  to  damage  from  ordnance  detonation  or  collisions  and  the  change  will  be 
included  in  outgoing  Entity  State  PDU’s..  ITB  movement  will  be  reflected  in  the  Entity  State  PDU’s,  and 
other  location/movement  information  will  be  included  in  outgoing  Bre,  Detonation,  and  Collision  PDU’s. 
In  all  cases,  this  information  will  be  converted  into  ECEF  or  entity  vector  formats  as  appropriate.  Release 
of  ordnance  by  the  ITB  will  cause  a  Fire  PDU  to  be  issued.  The  ITB  routine  that  computes  the  ballistic 
trajectory  of  the  released  ordrumce  will  supply  detail  for  the  Detonation  PDU.  Periodically,  die  code  that 
updates  the  locations  of  the  DIS  entities  will  check  whether  a  collision  with  the  ITB  has  occurred.  If  a 
collision  is  detected,  the  Collision  PDU  will  be  generated. 
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23  J  Tttik  Performance  Requirements 

Talde  2.3.3-1  summarizes  how  often  activities  related  to  DIS  must  be  fjerformed  by  the  enhanced  ITB 
software. 


Table  233~1  Task  Performance  Characteristics 


Activity 

Freauencr 

Notes 

Procan  noofluna  PDU 

Immediate,  upon  receipt 

Continuous  tqteratkm  as  Irnig  as  there 
are  unprocessed  PDU's 

Tranmit  outgoing  PDU 

Immediate 

Continuous  operation  as  long  as  diere 
are  PDU's  waiting  to  be  transmitted 

Dead  reckoning  of  DIS  entities 

16  Hz 

Synchronized  with  OTW/FLIR  displays 

Check  for  coDisions 

IHz 

Synchronized  with  dead  reckoning 

Remove  obsolete  potential  collisions 

IHz 

Synchronized  with  dead  reckoning 

Generate  Entity  Stale  PDU 

Immediate 

Caused  by  change  in  appearance, 
elapsed  time,  or  movement  beyond  dead 
reckening  thresholds 

Generate  Fne  PDU 

Immediate 

Release  of  ordnance 

Generate  Detonation  PDU 

Immediate 

Detonation  of  ordnance 

Generate  Collision  PDU 

Immediate 

When  ITB  software  determines  a 
coUisian  has  oocutred 

Generate  Rqiair/Resui^ly  PDU's 

Immediate 

Upon  receipt  of  Service  Request  PDU 

Conqnite  detonation  damage 

Immediate 

When  entry  added  to  Ordnance 
Detonation  Queue,  synchronized  ID 
aircraft  modeling 

Compute  collision  damage 

Immediate 

When  entry  added  to  Collision  Damage 
Queue,  synchronized  to  aircraft 
modeling 

2.4  Top  Level  Design 

Figure  2.4-1  illustrates  operation  of  the  ITB  using  DIS  to  exchange  information.  The  activity  of  the  other 
players  is  received  through  the  DIS  interface  instead  of  being  generated  internally  by  the  ITB.  The 
activity  of  the  ITB  is  transmitted  to  the  other  players  also  using  the  DIS  interface.  The  use  of  DIS  should 
be  transparent  to  the  ITB  “pilot” 
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port 


OTHER  PLAYER  ACTIVITY 
ITB  ACTIVITY 

ADVTECH-OCR-2 1 1  -062892 


Figure  2.4-1  ITB  Activity  Using  DIS 

The  top  level  design  for  the  implementation  of  DIS  capability  in  the  ITB  reflects  the  intuitive  notion  of 
transparency  of  DIS  operation.  Figure  2.4-2  illustrates  the  tasks  and  the  major  data  flows.  The  “pilot” 
interacts  with  the  ITB  through  the  use  of  the  cockpit  controls  and  displays.  The  OTW/FLIR  and  HUD 
displays  provide  additional  infonnadon  about  tire  environment.  None  of  this  will  change  when  DIS 
capabUity  is  implemented.  Instead,  the  new  DIS  information  will  operate  on  tire  internal  data  used  to 
support  the  ITB  internal  functions  and  displays. 


Development  to  Support  DIS  Capability  '  Existing  ITS  Software 
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Figure  2.4-2  ITB/DIS  Task  Interrelationships 
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2.4.1  Task  Functions 

The  ITB  software  consists  of  a  number  of  independently  executing  tasks.  Figure  2.4-2  illustrates  the 
ftmcdonal  relationship  of  these  tasks.  In  order  to  support  DIS  capability,  some  of  the  existing  ITB  tasks 
must  be  modifi^l.  and  other  new  tasks  must  be  developed.  The  new/modified  functionality  of  these  tasks 
is  outlined  in  this  section. 

2.4.1.1  Modifications  to  Existing  ITB  T a^s 

This  section  describes  the  modifications  that  must  be  made  to  the  existing  ITB  tasks  in  order  to  support 
DIS  capability. 

2.4.1.1.1  Aircraft/Flight  (AIRPLN,  EARTH) 

The  task  must  generate  an  Entity  State  PDU  whenever  the  thresholds  in  location,  orientation  or  time  have 
been  exceeded,  or  a  change  in  appearance  has  occurred.  Currently  in  the  ITB  code,  task  EARTH  updates 
the  aircraft  location  and  task  AIRPLN  updates  the  orientation,  velocities  and  accelerations.  The  EARTH 
task  will  be  integrated  into  .\IRPLN  to  simplify  these  operations.  The  AIRPLN  task  executes  64  times 
per  second.  Each  time  it  executes,  it  will  perform  a  dead  reckoning  update  of  itself.  The  actual  location 
and  orientation  will  be  compared  to  the  dead  reckoned  location  and  orientation.  Should  the  difference 
exceed  thresholds  establish^  during  initialization,  an  Entity  State  PDU  will  be  generated.  An  Entity 
State  PDU  will  be  generated  should  the  length  of  time  since  the  last  Entity  State  PDU  exceed  a  threshold 
established  during  initialization.  An  Entity  State  PDU  will  also  be  generated  when  the  aircraft  appearance 
changes.  This  can  be  caused  by  the  new  Collision  Assessment  and  Detonation  Assessment  tasks  to 
support  the  DIS  capability.  These  tasks  will  calculate  damage  to  the  aircraft  due  to  collision  or  detonation 
of  munitions.  When  a  PDU  is  generated,  it  will  be  placed  in  the  Unprocessed  Output  PDU  Queue. 

Reference  to  terrain  information  may  need  to  change.  ITB  software  is  hard-coded  for  a  specific  area. 
Changes  must  be  made  to  support  arbitrarily  specified  gaming  areas. 

2.4.1.U  Avionics  (Several  tasks) 

Avionics  tasks  will  be  virtually  unchanged.  References  to  terrain  information  for  devices  such  as  the 
altimeter  may  need  to  change  to  support  arbitrarily  specified  gaming  areas. 

2.4.1.U  Cockpit  Control/Display  (Several  tasks) 

Coclqiit  control  and  display  tasks  will  not  be  changed  by  this  effort. 

2.4.1.1.4  Head’s-Up  Display  (HUDBBN) 

The  Head’s-Up  Display  will  remain  virtually  unchanged.  The  only  modification  may  be  to  alter  the 
aircraft  location  and  orientation  values  slightly  to  compensate  for  differing  earth  models  and  terrain 
interpretations.  The  earth  and  terrain  models  underlying  the  HUD  are  not  known  as  of  this  writing. 

2.4.1.1.5  Laser  Ranger  (LSR) 

The  Laser  Ranger  task  will  be  virtually  unchanged.  References  to  terrain  information  may  change  to 
support  arlMtrarily  specified  gaming  areas. 
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2A.1.1J6  Out-the-Window/FUR  Display  (BBNINTERFACE) 

The  OTW/FLIR  Display  task  must  be  modified  to  display  the  other  DIS  entities.  The  Entity  Data 
Structure  will  contain  all  of  the  infonnation  necessary  to  produce  the  display.  The  task  will  convert  each 
entity’s  location,  orientation,  display  icon,  and  size  into  a  message  that  will  be  included  in  the  packet  to  be 
sent  to  the  display.  The  location  and  orientation  must  be  converted  from  the  ECEF  coordinates  in  the 
Entity  Data  Structure  to  the  ladtude/longitude/altitude  required  by  the  display. 

The  ITB  aircraft  location  and  orientation  values  may  be  altered  slightly  to  compensate  for  differing  earth 
models  and  terrain  interpretations. 

2.4.1.1.7  Weapon  System  (WEAPEX) 

The  Weapon  System  task  must  be  modified  to  generate  a  Fire  PDU  at  the  moment  when  an  MK-82  bomb 
is  released.  This  occurs  at  the  location  in  program  WEAPEX  where  subroutine  SCORE  is  called. 
Location  and  velocity  information  for  the  PDU  will  be  based  on  the  aircraft  information.  The  Fire  PDU 
will  be  placed  in  the  Unprocessed  Output  PDU  Queue. 

The  Weapon  System  task  must  also  be  modified  to  generate  a  Detonation  PDU  at  the  appropriate  time. 
Presently,  subroutine  SCORE  is  called  to  determine  miss  distance  from  the  intended  target  Subroutine 
TRAJEC  computes  the  critical  infoimation  of  location  and  time  of  detonation.  Since  the  flight  path  of  tlK 
bomb  is  ballistic  after  it  is  released,  this  infonnation  can  be  computed  at  the  time  that  the  Hre  PDU  is 
generated.  When  DIS  is  used,  routine  TRAJEC  will  be  called  directly.  Information  from  the  routine  will 
be  saved  until  the  computed  time  of  detonation,  at  which  time  the  Detonation  PDU  will  be  generated. 
The  Detonation  PDU  will  be  placed  in  the  Unprocessed  Output  PDU  Queue. 

2.4.1.2  New  ITB  Tasks 

This  section  describes  the  new  tasks  that  must  be  added  to  ITB  software  in  order  to  support  DIS 
capability.  Seven  new  tasks  are  required.  Each  of  the  seven  tasks  will  be  started  by  the  ADSS  Executive 
and  perfoim  initialization  functions  before  simulation  beiilns.  None  of  the  tasks  execute  continuously. 
Some  execute  cyclically  at  a  fixed  rate,  triggered  by  the  ADSS  Executive.  Others  are  data  driven, 
executing  only  when  there  is  data  available.  Table  2.4.1.2-1  summarizes  these  task  attributes. 


Table  2.4.1  J-l  Execution  Attributes  of  New  Tasks 


New  Task 

Operation 

Collision  Assessment 

Data  driven,  when  data  in  the  Collision  Damage  Queue. 

Dead  Reckoning 

16  Hz.  controlled  by  the  executive. 

Detonation  Assessment 

Data  driven,  when  data  is  in  the  Ordnance  Detonation  Queue. 

Elhemet  Input 

Data  driven,  when  PDU  received  over  Ethernet. 

Ethernet  Output 

Data  driven,  when  data  is  in  the  Unprocessed  Output  PDU  Queue. 

ITB  Collision  Evaluation 

1  Hz.  controlled  by  the  executive. 

PDU  Processing 

Data  driven,  when  data  is  in  the  Unprocessed  Ii^ut  PDU  Queue. 
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2.4,12.1  Collision  Assessment 

The  Collision  Assessment  task  will  determine  damage  caused  to  the  ITB  after  collision  with  another 
entity.  This  task  executes  only  when  a  conhimed  collision  has  occurred,  that  is.  when  both  the  ITB  and 
the  other  entity  have  independently  deteiroit^d  that  a  collision  has  occurred.  The  damage,  if  any,  will 
manifest  itself  in  changes  to  the  airframe  and  aircraft  appearance.  The  resultant  Entity  State  PDU  will  be 
generated  by  the  Aircraft  Control  task. 

The  Collision  Assessment  task  will  execute  only  when  there  are  entries  in  the  Collision  Damage  Queue. 
Both  the  ITB  Collision  Evaluation  task  and  the  PDU  Processor  can  place  items  in  the  queue.  The 
Collision  Assessment  task  wUl  be  started  if  it  is  not  already  executing  when  this  occurs.  It  will  remove 
the  queued  damage  information,  which  consists  of  pertinent  information  from  the  Collision  PDU’s.  The 
information  used  to  determine  damage  includes  the  mass  of  the  entities,  their  velocities,  and  the  points  of 
contact  of  each  entity.  The  actual  damage  evaluation  algorithm  to  be  used  has  not  yet  been  determined, 
and  will  be  deferred  until  Hiase  II. 

2.4.122  Dead  Reckoning 

The  Dead  Reckoning  task  will  be  responsible  for  performing  dead  reckoning  updates  for  all  of  the 
external  DIS  entities.  Dead  reckoning  information  is  included  in  each  Entity  State  PDU  and  will  be 
stored  in  the  Entity  Data  Structure.  This  task  will  execute  at  a  16  Hz  rate  and  win  be  synchronized  widi 
the  Out-the-Window/FLIR  Display  task  so  that  these  displays  always  have  current  information.  Dead 
redconing  calculations  will  be  performed  with  ECEF/Entity  coordinates  using  the  formulas  from  the 
document  “Protocol  Data  Units  for  Entity  Infonnation  and  ^tity  Interaction  in  a  Distributed  Interactive 
Simulation,"  Appendix  I.  Other  tasks  that  use  the  dead  reckoned  information  will  be  responsible  for 
converting  coordinates  into  those  appropriate  for  their  application. 

2.4.1,23  Detonation  Assessment 

The  Detonation  Assessment  task  will  determine  damage  caused  to  the  ITB  after  detonation  of  ordnance. 
The  task  executes  only  when  a  Detonation  PDU  has  been  received.  The  damage,  if  any,  will  manifest 
itself  in  changes  to  the  airframe  and  aircraft  appearance.  The  resultant  Entity  State  PDU  will  be  generated 
by  the  Aircraft  Control  task. 

The  Detonation  Assessment  task  will  execute  only  when  there  are  eruries  in  the  Ordnance  Detonation 
Queue.  The  Detonation  Assessment  task  will  be  started  if  it  is  not  already  executing  when  this  occurs.  It 
will  remove  the  queued  information,  which  consists  of  pertinent  information  ftom  the  Detonation  PDU. 
The  information  used  to  determine  damage  includes  the  type  of  ordnance,  the  relative  location  of  the 
detonation  to  the  ITB,  and  the  orientation  of  the  ITB.  The  actual  damage  evaluation  algorithm  to  be  used 
has  not  yet  been  determined,  and  will  be  deferred  until  Phase  II. 

2.4.12.4  Ethernet  Input 

The  Ethernet  Input  task  will  be  responsible  for  efficient  management  of  the  Ethernet  local  area  network 
(LAN).  Since  DIS  typically  operates  using  an  unreliable  data  exchange  protocol,  it  is  important  that  the 
input  task  be  capable  of  accepting  input  at  any  time.  To  minimize  ITB  processing  delays,  the  task  must 
place  PDU’s  in  the  Unprocessed  Input  PDU  Queue  as  quickly  as  possible.  The  Ethernet  Input  task  will  be 
coded  with  both  of  these  concerns  taken  into  consideration.  The  task  will  be  started  by  the  Affiant 
computer’s  operating  system  whenever  a  PDU  is  received.  It  will  continue  to  execute  as  along  as  PDU’s 
continue  to  be  received.  “Read  ahead’’  buffers  will  be  used  so  that  PDU’s  will  not  be  dropped  should  the 
task  be  busy  when  a  PDU  arrives.  The  Ethernet  Input  task  starts  the  PDU  Processor  task  when  a  PDU  is 
placed  in  the  Unprocessed  Input  PDU  Queue. 
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It  is  assumed  that  the  AUiant  computer  system  is  capable  of  imploiumting  whatever  OSI  standard  is  used 
for  communication.  Amherst  Systems  will  code  any  software  above  the  driver  level  that  is  required  to 
implement  the  desired  protocol.  If  it  turns  out  that  the  Ethernet  driver  software  or  hardware  is  not  capatde 
of  sui^rting  I/O,  additional  procurement  by  WL/AAAS-2  may  be  requited. 

2.4.1^  Ethernet  Output 

The  Ethernet  Output  task  will  output  ITB  generated  PDU’s  as  quickly  as  possible  over  the  Ethernet  LAN. 
PDU’s  can  be  generated  by  a  number  of  ITB  tasks.  Simultaneous  generation  of  PDU’s  and  the  possibility 
that  the  Ethernet  could  be  busy  means  that  it  may  not  be  possible  to  transmit  a  PDU  immediately  alter  it  is 
created.  Irrstead  of  making  time  critical  tasks  wait  until  the  PDU  is  transmitted,  the  PDU’s  will  be  placed 
in  a  queue.  The  Ethernet  Output  task  will  remove  PDU’s  from  the  queue  and  transmit  them  over  the 
Ethernet  to  other  DIS  sites.  The  Ethernet  Output  task  will  be  started  whenever  a  PDU  is  added  to  the 
queue.  It  will  continue  to  execute  as  long  as  PDU’s  remain  in  the  queue. 

It  is  assumed  that  the  AUiant  computer  system  is  capable  of  implementing  whatever  OSI  standard  is  used 
for  communication.  Amherst  Systems  wiU  code  any  software  above  the  driver  level  that  is  required  to 
implonent  the  desired  protocol.  If  it  turns  out  that  the  Ethernet  driver  software  or  hardware  is  not  capable 
of  supporting  I/O,  additional  procurement  by  WL/AAAS-2  may  be  required. 

2.4. U,6  ITB  Collision  Evaluation 

The  1TB  CoUision  Evaluation  task  wiU  determine  whether  the  ITB  has  collided  with  another  entity.  It 
wiU  be  executed  at  a  rate  to  be  determined.  The  task  wiU  compare  the  ITB  location,  orientation,  shape, 
and  size  with  aU  other  entities’  data  using  an  algoriUim  to  be  developed  in  Phase  n.  If  the  ITB  determines 
that  a  collision  has  occurred,  it  wiU  generate  a  CoUision  PDU,  add  it  to  the  Unprocessed  Output  PDU 
Queue,  and  start  the  Ethernet  Output  task  if  it  is  not  yet  executing.  AdditionaUy,  the  entity  record  for  the 
coUiding  entity  wUl  be  examined  to  see  if  a  concurrent  PDU  has  been  received  confirming  the  coUision. 
If  so,  information  from  the  record  will  be  placed  in  the  CoUision  Damage  Queue,  the  Collision 
Assessment  task  wiU  be  started  if  it  is  not  yet  executing,  and  coUision  information  in  the  record  wiU  be 
cleared.  If  there  is  no  confirming  coUision  data,  the  time  of  the  evaluation  wiU  update  the  record. 

2.4. U.7  PDU  Processor 

The  PDU  Processor  task  processes  each  of  the  PDU’s  received  from  other  DIS  sites.  The  PDU  Processor 
is  started  by  the  Ethernet  Input  task.  It  takes  a  PDU  from  the  Unprocessed  Input  PDU  Queue  and 
performs  processing  as  described  below.  The  PDU  Processor  task  wiU  continue  to  execute  as  long  as 
PDU’s  remain  in  the  Unprocessed  Input  PDU  Queue. 

a.  Entity  State  PDU;  The  Entity  Data  Structure  wUl  be  examined  to  see  if  the  entity 
already  exists.  If  the  entity  does  not  yet  exist,  the  foUowing  special  processing  wUl  be 
performed. 

•  A  new  record  for  the  entity  wiU  be  created  in  the  Entity  Data  Structure. 

•  Information  about  the  entity  type  wiU  be  retrieved  ftom  the  Entity  Database  and 
added  to  the  record. 

The  record  in  the  Entity  Data  Structure  wiU  receive  updated  movement  information 
from  the  PDU.  The  location  and  orientation  placed  into  the  record  wUl  reflea  a  dead 
reckoned  update  from  the  time  of  the  PDU  to  the  time  of  the  processing. 
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i).  FiitPDU:  The  entity  record  in  the  State  PDU  will  be  updated  to  reflect  the  fact 
that  the  entity  has  fli^. 

c.  Detonation  PDU:  Information  about  the  munition,  time  of  detonation  and  location  of 
detonaticm  will  be  placed  in  the  Ordnance  Detonation  Queue.  If  the  munitioa  is 
rqvesmited  as  a  separate  entity,  a  flag  will  be  set  in  its  record  in  the  Entity  Data 
Structure  to  indicate  that  it  has  detonated.  The  Detonation  Assessment  task  wtU  be 
started  if  it  is  not  currently  executing. 

d.  Collision  PDU:  The  entity  record  for  the  colliding  entity  will  be  examined  to  see  if  the 
ITB  has  concurrently  determined  that  a  collision  has  occurred.  If  so,  all  collisitm 
information  in  the  record  will  be  cleared,  information  from  the  Collision  PDU  will  be 
placed  in  the  Collision  Damage  Queue,  and  the  Collision  Assessment  task  will  be 
started  if  it  is  not  yet  executing.  If  there  is  no  concurrent  collision,  information  fiom 
the  Collision  PDU  will  update  the  record. 

e.  Service  Request  PDU:  If  the  service  request  is  for  supplies,  a  Resuj^ly  Cancel  PDU 
will  be  generated.  If  the  service  request  is  for  repairs,  a  Repair  Complete  PDU  (with 
“no  repairs  performed”)  will  be  generated.  The  PDU  will  be  placed  in  the 
Unprocessed  Ouqrut  PDU  Queue  and  the  Ethernet  Ouqrut  task  will  be  started  if  it  is 
not  currently  executing. 

f.  Other  PDU’s:  All  other  PDU’s  will  be  ignored. 

2.4  Special  Areas  of  Investigation 

This  section  discusses  areas  of  significant  technical  importance  for  the  successful  completion  of  Phase  n 
work. 

The  following  paragr^hs  will  describe  the  relationships  between  the  coordinate  systems  used  by  both 
DIS  and  the  ITB  aircraft  model.  Each  paragrt^h  will  be  divided  into  three  sections.  The  first  section  win 
describe  the  position  and  movement  data  from  the  perspective  of  the  ITB  cockpit  (i.e.  what  does  the  ITB 
have  that  is  required  by  the  DIS  network?).  The  second  section  will  describe  the  position  and  movement 
data  fiom  the  perspective  of  the  DIS  network  (i.e.  what  does  the  DIS  network  have  that  is  required  by  die 
ITB  cockpit?).  The  third  section  will  provide  the  solution  (or  methodology)  of  transferring  the  position 
and  movement  data  between  the  ITB  and  DIS  worlds.  Other  coordinate  transforms,  such  as  di^  that 
apply  to  both  the  Out-The- Window  (OTW)  and  Heads-Up-Display  (HUD)  displays  can  be  performed  in  a 
similar  manner.  Currendy,  however,  we  do  not  have  all  of  the  data  necessary  to  completely  define  these 
transformations.  Properly  solving  these  transformations  will  be  an  important  part  of  tte  nia%  n  effort 

The  following  provides  a  list  of  the  Entity  State  PDU  position  and  movement  data  items  of  interest 
Readers  Note:  The  information  contained  within  the  parenthesis  references  paragraphs  from  the 
document  endded  “Protocol  Data  Units  for  Endty  Informadon  and  Endty  Interacdon  in  a  Distributed 
Interacdve  Simuladon”  Military  Standard  Final  Draft  30  October  1991. 

1.  Coordinate  System  Geometry  •  Ineitial/World  Coordinate  Reference  (5.2.21) 

2.  Coordinate  System  Geometry  -  Endty  Coordinate  Reference  (5.2.20.1) 

3.  Linear  Velocity  Vector  (5.2.20.3) 

4.  Linear  Acceleradon  Vector  (5 .2.20.2) 
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5.  Angular  Velocity  Vector  (5.2.1  and  5.2.2) 

6.  Entity  Location  (5.2.21) 

7.  &itity  Oiientation(Euler  Angles  (3.14, 5.2.1  and  5.2.1 1) 

8.  Dead  Reclaming  (522, 5.2.20.2  and  Aiq)endix  I) 

2A2.ini  Coordinate  System  Geometry  •  Inertial/World  Coordinate  Reference 

When  formulating  and  solving  problems  in  flight  dynamics,  a  number  of  flames  of  reference  (coordinate 
axis)  must  be  used  for  specifying  various  parameters.  Techniques  must  also  exist  to  allow  for  the 
tran^ormation  of  quantities  from  one  coordinate  system  to  another.  In  order  for  Newtons  second  law  of 
motion  (F=ma)  to  hold  true  at  all  times,  one  of  fliese  systems  must  be  fixed  to  the  earth.*  Such  a  system 
is  denoted  as  the  Inertial  (or  World)  Coordinate  Reference  System. 

The  next  few  paragraphs  describe  the  ITB  North-East- Vertical  (NEV)  Inertial  Coordinate  reference 
system,  the  DIS  Earth-Centered-Earth-Fixed  (ECEF)  Inertial  Coordinate  reference  system  and  the 
methodology  requited  to  translate  between  the  two  systrans. 

2.4,2.1.1.1  ITB  North-East- Vertical  (NEV)  Reference  System 

In  many  problems  of  airplane  dynamics,  the  rotation  of  the  Earth  can  be  neglected  and,  as  such,  any 
reference  flame  fixed  to  Ae  Earth  can  be  used  as  an  inertial  frame.  The  ITB  simulator  employs  such  an 
inertial  coordinate  system  (named  North-East-Vertical  (NEV)).  NEV  is  an  Earth-surface  frame  with  its 
origin  fixed  at  die  end  of  the  runway  where  the  ITB  simulator  is  initialized.  The  following  applies  to  the 
ITB  NEV  coordinate  system: 

1.  XAxis:  Positive  direction  points  to  die  North  Pole. 

2.  YAxis:  Positive  direction  points  to  the  East. 

3.  Z  Axis:  Positive  direction  points  along  the  local  gravity  vector  and  perpendicular  to 
the  surface  of  the  Earth.  Since  the  ITB  Earth  model  is  an  ellipsoid  (see  ^e  definition 
of  the  ITB  Earth  model  and  Figure  2.4.2. 1. 1.3-2),  this  vector  (for  the  most  part)  does 
not  go  through  the  center  of  the  Earth.  The  exceptions  to  this  rule  occur  at  the  Equator 
and  the  Poles. 

4.  Origin:  Fixed  at  the  end  of  the  runway  where  the  ITB  simulator  is  initialized. 

5.  Earth  Model:  World  Geodetic  System  1984  (WGS-84)  ellipsoid  with  a  semi-major 
axis  (a)  of  6,378,137  meters  and  a  semi-minor  axis  (b)  of  6,356,752.3142  meters. 

An  illustration  of  the  NEV  coordinate  system  is  provided  in  Figure  2.4.2.1. 1.3-1. 


*  If  a  is  the  acceleration  relative  to  a  reference  flame  that  has  either  a  rotation  and/or  acceleration  of  its  origin, 
Newton’s  second  law  (Fsrna)  does  not  hold,  as  additional  terms  that  depend  upon  the  motion  of  reference  flame 
have  to  be  added  to  the  equation. 
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2AJA.12  DIS  Eartti>Ceiitered-Earth-rixed  (ECEF)  Reference  System 

In  order  to  account  for  the  rotation  of  the  Earth,  the  DIS  standard  requires  that  the  origin  of  its  inertial 
ftame  be  fixed  at  the  centroid  of  the  Earth  (ECEF).  The  following  relies  to  the  DIS  ECEF  ineitial 
cootdiitate  system: 

1.  X  Axis:  Positive  direction  passes  through  the  Prime  Meridian  at  the  Equator  (0 
Degrees  Latitude,  0  Degrees  Longitude). 

2.  Y  Axis:  Positive  direction  passes  through  90  degrees  East  Longitude  at  the  Equator  (0 
Degrees  Latitude,  90  Degrees  East  Longitude). 

3.  ZAxis:  Positive  direction  passes  through  the  North  Pole. 

4.  Origin:  Fixed  at  the  centroid  of  the  Earth. 

5.  Earth  Model:  World  Geodetic  System  1984  (WGS-84)  ellipsoid  with  a  semi-major 
axis  (a)  of  6,378,137  meters  and  a  semi-minor  axis  (b)  of  6,356,752.3142  meters. 

An  illustration  of  the  ECEF  coordinate  system  is  provided  in  Figure  2.42.1.1.3-1. 

2.42.1.U  NEV-ECEF  Coordinate  Transformation  Methodology 

As  was  discussed  in  the  preceding  paragraphs,  there  are  inherent  differences  between  the  ITB  NEV 
inertial  coordinate  system  (whereby  the  origin  is  fixed  on  the  surface  of  the  Earth)  artd  the  DIS  ECEF 
inertial  coordinate  system  (whereby  the  origin  is  fixed  at  the  center  of  the  Eardi).  In  order  to  resolve  these 
differences  and  properly  lepresoit  the  ITB  coclqrit  in  the  DIS  world  and.  in  turn,  DIS  Entities  in  the  ITB 
world,  an  NEV-ECEF  transformation  matrix  has  to  be  developed.  Figure  2.4.2. 1.1. 3-1  illustrates  the 
relationship  between  the  NEV  and  ECEF  coordinate  systems. 


The  transformations  involve  the  following  variables: 
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1.  Geocentric  Latitude  (^):  That  latitude,  positive  as  measured  from  die  Equattu’  to  the 
North  Pole,  asnuning  a  sfdierical  earth. 

2.  Oeod^  Latitude  (A)  That  latitude,  positive  as  measured  frtmi  the  Equator  to  the 
Nofdi  Pole,  assuming  a  WGS-g4  elliptical  Eardt  This  is  the  latitude  as  supfdied  by 
the  rTB  simulator. 

3.  Earth  Radius  (r^:  The  radius  of  the  Earth  as  a  function  of  die  Geocentric  Latitude 

4.  Geocentric/Geodetic  Longitude  (ji)  That  longitude  positive  as  measured  ftom  (0 
Latitude,  0  Longitude)  to  (0  Latitude.  90  East  Longitude).  Note  that  die  Geocoitric 
Longitude  is  equal  at  all  times  to  the  Geodetic  Longitude. 

A  brwf  description  of  the  NEV  to  ECEF  coordinate  transfer  methodology  is  as  foUows: 

1.  Determine  the  relatitmship  between  a  Geocentric  (^dierical)  and  Geodoic  (elliptical) 

Earth  in  tenns  of  their  respective  Latitude  angles  (d=/(A)  and  As/(^)). 

2.  Determine  the  radius  of  the  Geodetic  Earth  as  a  function  of  its  Geocentric  Latitude 

(xHm- 

3.  Detennine  the  homogeneous  translation/rotation  matrix  to  convert  from  an  NEV 
inertial  coordinate  system  to  an  ECB^  inertial  coordinate  system: 

a.  Provide  the  standard  Euler  Angle  rotation  matrices. 

b.  Rotate  die  NEV  coordinate  system  about  the  axis  in  order  to  align  the  NEV 
and  ECEF  origins. 

c.  Rotate  the  NEV  coordinate  system  about  the  Ybcep  axis  in  order  to  compensate 
for  the  Geodetic  altitude  vector. 

d.  Translate  the  NEV  coordinate  system  along  the  Xecsf  axis  to  the  previously 
calculated  radius  of  Geodetic  Earth  (r^). 

e.  Rotate  the  NEV  coordinate  system  about  the  YscEpaxis  to  the  Geocentric 
Latitude. 

f.  Rotate  the  NEV  coordinate  system  about  the  Zbcef  axis  to  the  Geocentric/ 
Geodetic  Longitude. 

g.  Concatenate  all  of  the  rotations  and  translations  to  form  the  homogeneous  NEV- 
ECEF  transformation  matrix. 

Figure  2.4.2.1.1.3-2  illustrates  the  relationship  between  the  Geocentric  and  Geodetic  Earth.  Using  diis 
figure  as  wdl  as  Figure  2.4.2.1.1.3-1,  die  next  few  paragraphs  describe  the  transfer  methodology  in  detaiL 
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Step  1:  Uang  Figure  2.4.2. 1.1. 3*2.  the  relation^p  between  the  Geocentric  and  Geodetic  Eairii  in  tenns 
of  teir  respective  latitude  angles  (^/(A)  and  As/(^))  can  be  derived  as  follows: 
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The  equation  of  an  ellipse: 

^1  +  ^  =  1 
a*  b* 

(1) 

Taking  partial  derivatives: 

2x9x  ^2y^y 
a*  b* 

(2) 

Reartarrgirrg: 

dy  b*^x' 
dx~  a%y. 

(3) 

The  slope  of  the  tangent  at  T: 

=  ^/^x 

=-tan(90-A) 

=-cotanA 

=-l/tanA 

or  combining: 

_ 

^x.  tanA 

(4) 

The  slope  of  R: 

=  tanA 

From  (4): 

--dx!  dy 

From  (3): 

Combining: 

(5) 

The  slope  of  n 

V 

tan0  =  — 

X 

(6) 

Therefore  from  (5)  and  (6): 

tanA=— tand 
b* 

(7) 

From  (7): 

b*  , 
tan^s-rtanA 
a 

(8) 

From  (7): 

(9) 

From  (8): 

p  =  arcian^^tanAj 

(10) 

Step  2:  Using  Hgure  2.4.2. 1. 1.3-2,  the  radius  of  the  Geodetic  Earth  as  a  ftinction  of  its  Geocmtric 
Latitude  (r/B/(p))  can  be  derived  as  follows: 
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The  equation  of  an  ellipse: 

a*  b* 

(1) 

Rearranging: 

aV=bV  +  aV 

(2) 

Pydiagorean  idaiimi: 

r^  =  x»  +  y* 

(3) 

Also: 

y  =  r,sin^ 

(4) 

Squaring  (4): 

y*  =  r*sin*^ 

(5) 

Substituting  (4)  into  (3): 

r;^  =  X*  +  r*sin*^ 

(6) 

Rearranging  (6): 

X*  =  r;J  -  r*sin*^ 

(7) 

Substituting  (7)  &  (5)  into  (2): 

a  V  =  b*(r*  -  r;JsinV)  +  aV*sin  V 

(8) 

Solving  (8)  forr^: 

(9) 

Stqp  3:  Using  Hgure  2.4.2.1. 1.3-1  detennine  the  translation/rotation  matrix  to  ctmveit  from  an  NEV 
inertial  coordinate  system  to  an  ECEF  inertial  coordinate  system.  For  the  most  part  in  this  step, 
b(»nogeneous  matrices  will  be  used.  Homogeneous  matrices  are  four-by-four  matrices  that  ctmtain  bodi 
the  rotation  and  translation  components.  The  first  3  rows  by  3  columns  (9  elements)  contain  the  rotatirm 
cmnponent;  the  last  column,  fiist  3  rows  (3  elements)  contain  the  translation  component  Note  that  for  the 
rotation  component  the  standard  Euler  Angle  rotation  matrices  will  be  used. 

a.  Euler  Angle  Rotation  Matrices:  The  orienution  of  any  reference  frame  relative  to 
another  can  be  given  by  three  angles  whidr  are  the  consecutive  rotations  about  the  Z 
axis  through  an  angle  y,  about  the  Y  axis  through  an  angle  0,  and  about  the  X  axis 
through  an  angle  0  (in  that  order).  These  angles  are  used  to  carry  one  frame  of 
reference  in  coinddence  another.  In  flight  dynamics,  the  Euler  Angles  are  those 

which  rotate  the  body  (r  axis  system  into  coincidence  with  the  inertial  reference 

frame.  The  Yaw,  Pitdi,  and  Roll  matrices  can  be  givoi  as  follows: 
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Cosy 

•Siny 

O' 

Rotation  About  the  Z  Axis  (Yaw) = 

Siny 

Cosy 

0 

0 

0 

1_ 

’  Cos6 

0 

Sin6l 

Rotation  About  the  Y  Axis  (Pitch)  = 

0 

1 

0 

-Sind 

0 

Cos^J 

■  1 

0 

0 

1 

Rotatioi  About  the  X  Axis  (Roll) = 

0 

COs^i 

'Sin^ 

0 

Sin^ 

Cos^ 

b.  Rotate  NEV  about  YtcEFto  Align  NEV-ECEF  Origins:  Using  the  matrices 
developed  in  (a)  above,  we  must  first  convert  the  NEV  origin  coordinates  to  ECEF 
origin  coordinates.  In  order  to  align  the  coordinate  systems,  one  rotation  of  '90 
(tegrees  about  the  Yscspaxis  is  required.  The  matrixM^  describes  die  origin  rotation 
of  the  NEV  coordinate  system  about  the  Ybcep  axis  and  relative  to  the  fixed  origin  of 
the  ECEF  coordinate  system: 


■Cos(-90) 

0 

Sin(-90) 

O' 

■  0 

0 

-1 

O' 

0 

1 

0 

0 

0 

1 

0 

0 

-Sin(-90) 

0 

Cos(-90) 

0 

1 

0 

0 

0 

0 

0 

0 

1 

0 

0 

0 

1 

c.  Rotate  NEV  about  YicErto  Compensate  for  the  Geodetic  Altitude  Vector:  Using 
the  matrices  developed  in  (a)  above,  we  must  now  compensate  for  the  misalignment  of 
the  NEV  normal  arid  the  veaor  through  the  Earth’s  center.  This  difference  aj^iears  as 
a  result  of  the  inherent  differences  between  the  spherical  and  elliptical  Earth  models 
(refer  back  to  Figure  2.42.1.1.3-2).  In  essence,  the  NEV  coordiriate  system  must  be 
rotated  about  the  Ybcef  through  the  difference  between  the  Geodetic  and 
geocentric  Latitude  angles  (^A)  such  that  the  final  result  produces  a  Zhev  axis  aligned 
with  R.  The  matrix  describes  the  rotation  of  the  NEV  coordinate  system  abmit 
the  Ybcef  axis  and  relative  to  the  fixed  origin  of  the  ECEF  coordinate  system: 

M"=Mb(Ybcbp.0-A) 


'  Cos(0-A) 

0 

-©• 

1 

s...' 

O' 

0 

1 

0 

0 

-Sin(0  -  A) 

0 

Cos(0-A) 

0 

0 

0 

0 

1 
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d.  Translate  NEV  Along  XsccfIo  Radius  of  Geodetic  Earth  (r^:  We  must  now 
translate  the  entire  NEV  coordinate  system  along  the  X^T^axis  by  the  radius  of  the 
Geodetic  Earth  (r«)  as  derived  in  Step  2  above.  The  matrix  M"  describes  the 
translation  of  the  coordinate  system  along  the  Xbcbf^  relative  to  the  fixed 
origin  of  the  ECEF  coordinate  system; 

MS 

0  0  r/ 

1  0  0 

0  1  0 

0  0  1 


e.  Rotate  NEV  about  Ytcirto  Geocoitric  Latitutte:  Using  the  matrices  developed  in 
(a)  above,  we  must  now  orient  the  ZNEvtutis  perpendicular  to  the  surface  of  the  Earth. 
In  essence,  the  NEV  coordinate  system  must  be  rotated  about  the  Ybcv  axis  through 
the  Geocentric  Latitude  angle  (-d)  such  that  the  final  result  produces  a  Zmev  »is 
perpendicular  to  the  surface  of  the  Earth  at  the  Geocentric  Latimde  of  the  point  in 
quesdorL  The  matrix  describes  the  rotation  of  the  NEV  coordinate  system  about 
the  YecBpaxis  relative  to  the  fixed  origin  of  the  ECEF  coordinate  system: 

0  Sm(-A)  O' 

1  0  0 

0  Cos(-A)  0 

0  0  1 


M*'*  = 


Cos(-A) 

0 

-Sin(-A) 

0 


f.  Rotate  NEV  about  ZccErto  Geocentric/Geodetic  Longitude:  Using  the  matrices 
developed  in  (a)  above,  we  must  now  orient  the  Xnev  axis  North  ar^l  the  Ynev  axis  East 
In  essence,  the  NEV  coordinate  system  must  be  rotated  about  the  Z^Bpaxis  dirough  the 
Geocentric/Geodetic  Longitude  angle  (jj)  such  that  the  final  result  produces  a  X^ev  axis 
that  points  North,  a  Ynev  axis  that  points  East  and  a  Znbv  axis  that  points  down  (and 
perp^icular  to  the  surface  of  the  Earth)  at  the  Geocoitric/Geodetic  Longitude  of  the 
point  in  question.  The  matrix  describes  the  rotation  of  the  NEV  coordinate 
system  about  the  ZecEpaxis  relative  to  the  fixed  origin  of  the  E(XF  coordinate  system: 
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'  CosOz)  -SinOz)  0  O' 

SinOz)  Cos(/z)  0  0 

0  0  0  0 

0  0  0  1 


g.  NEV  Relative  to  ECEF  Matrix:  To  finalize  the  process,  we  must  now  concatenate 
all  of  the  matrices  developed  in  (b)  through  (f).  Therefore,  the  NEV  Relative  to  ECEF 
Matrix  can  be  given  as: 

M|Sii=M^xM^xM;^xM“  xM2? 


Or,  explicitly; 

0  0irCa((-#)0  Sm(-^)  Ol  T 1  0  0  t^irCoK^-A)  0  SinZ# - 1)  Ol  [  0  0-1  O' 

_  SinZM)  CdOl)  00  0  I  0  00100  0  1  0  00100 

0  0  0  0  '  -Sin(-#)0  CotZ-#)  0*00  1  0  ‘  -Sin(f-/l)  0  Coi(^-A)0  '  1  0  0  0 

,0  0  OlJl.0  0  0  lJ1.000  lJ[  0  0  0  lj[000  1. 

Finally,  multiplying  the  NEV  Relative  to  ECEF  Matrices,  we  obtain  s 


'C{m)*[C(-^)*S(«-A)  +  S(-^)-C(^-A)1  ~S{u)  COi)*[S(-^)»S(^-A)-C(-^).C(^-A))  r.«C(-^)C(M)' 

S(mHC(-^)*S(^-'^)  +  S(-^).C(^-A)]  C(m)  SOiHs(-^)*S(^-A)-C(-^)«C(^-A)]  r,.C(-^)S(;i) 

0  0  0  0 

0  0  0  1 

2A^.12  Coordinate  System  Geometry  •  Entity  Coordinate  Reference 

The  entity  (sometimes  called  vehicle  or  body)  fixed  reference  frame  is  a  coordinate  system  in  whidi  the 
origin  is  attached  (fixed)  to  the  entity  at  its  center  of  mass  (C).  The  next  few  paragraphs  describe  the  FTB 
body-fixed  reference  system,  the  DIS  entity-fixed  reference  system  and  the  metrology  required  to 
translate  between  the  two  systems. 

ITB  Body  Fixed  Reference  System 

The  definition  of  the  coordinate  system  for  the  ITB  body-fixed  reference  frame  is  such  that  the 
conventions  for  posi.ive  rotation  of  the  platform  through  Roll,  Pitch  and  Yaw  correspond  to  positive 
rotations  in  a  right-handed  coordinate  system.  As  a  result,  the  following  is  true  for  the  FTB  body-fixed 
reference  frame: 

1.  X  (U)  Axis:  Positive  direction  points  forward  and  aligned  with  the  fuselage  reference 
line. 
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2.  Y  (V)  Axis:  Popendicular  to  the  X  axis  with  the  positive  direction  pointing  out  die 
staiboa: !  (right)  wing. 

3.  Z  (W)  Axis:  Completes  the  right-handed  coordinate  system  with  the  positive 
direction  pointing  downward. 

4.  Ori^:  Located  at  the  center  of  mass  of  the  body. 

An  illustratkm  of  the  ITB  body-fixed  reference  frame  is  provided  in  Figure  2.42.12.1-1. 


Figure  2.4J.12.1-1  ITB  Body-Fixed  Coordinate  System 
2.42.122  DIS  Entity  Fixed  Reference  System 

The  definition  of  the  coordinate  system  for  the  DIS  entity-fixed  reference  frame  is  such  that  the 
conventions  for  positive  rotation  of  the  platform  through  Roll,  Pitch  and  Yaw  correspond  to  positive 
rotations  in  a  right-handed  coordinate  system.  As  a  result,  the  following  is  true  for  the  DIS  entity-fixed 
reference  frame; 


1.  XAxis:  Extends  in  the  positive  direction  out  the  ftont  of  the  entity. 

2.  Y  Axis:  Extends  in  the  positive  direction  out  the  right  side  of  the  oitity  as  viewed 
from  above,  facing  in  the  positive  direction  of  the  X  axis. 

3.  Z  Axis:  Completes  the  right-handed  coordinate  systm.  It  extends  in  the  positive 
direction  downward. 

4.  Origin:  Located  at  the  center  of  the  bounding  volume  of  the  entity. 

An  illustration  of  the  DIS  entity-fixed  reference  frame  is  provided  in  Figure  2.4.2.1.22-1. 
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Figure  2.4J.UJ-1  DIS  Entity-Fixed  Coordinate  System 

2.42.123  ITB-DIS  Body-Fixed  Coordinate  Transformation  Methodology 

The  ITB  body-fixed  and  DIS  entity-fixed  reference  systems  are  coincident  (the  same).  No  rotations  or 
translations  (transformations)  are  requited. 

2.42.13  Linear  Velocity  Vector 

The  DIS  environment  requires  a  linear  velocity  vector  definition  for  the  entity  in  question.  The  next  few 
paragraphs  describe  the  ITB  linear  velocity  vector,  the  DIS  linear  velocity  vector  and  the  methodology 
required  to  translate  between  the  two. 

2.42.13.1  ITB  Aircraft  Linear  Velocity  Vector 

The  ITB  supplies  the  aircraft  linear  velocity  vector  in  Feet/Second  as  referenced  to  the  ITB  inertial  (NEV) 
coordinate  system.  This  vector  is  calculated  in  subroutine  LINVEL  of  program  AIRPLN  and  given  the 
following  symbols: 

1.  XIDOTF:  Velocity  of  the  aircraft  in  the  X  direction  C'North”)  with  respect  to  the 
NEV  inertial  coordinate  system.  Units  are  Feet/Second. 

2.  YIDOTF:  Velocity  of  the  aircraft  in  the  Y  direction  (“East”)  with  respect  to  the  NEV 
irrerdal  coordinate  system.  Units  ate  Feet/Second. 

3.  ZIDOTF;  Velocity  of  the  aircraft  in  the  Z  direction  (“Down”)  with  respect  to  the 
NEV  inertial  coordinate  system.  Units  are  Feet/Second. 
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2AJ2.132  DIS  Entity  Linear  Veiodty  Vector 

DIS  requires  the  entity  linear  velocity  vector  to  be  in  Meters/Second  as  referenced  to  the  ECEF  inertial 
coordinate  system.  The  following  applies  for  the  DIS  entity  linear  velocity  vector 

1.  X  Linear  Velocity  (X^y)*  Velocity  of  the  entity  in  the  X  direction  with  respect  to 
ECEF  coordinates.  Units  are  in  Meters/Second. 

2.  Y  Linear  Velocity  (Ylv):  Velocity  of  the  entity  in  the  Y  direction  with  respect  to 
ECEF  coordinates.  Units  are  in  Meters/Second. 

3.  Z  Linear  Velocity  (Z^y):  Velocity  of  the  entity  in  the  Z  direction  with  respect  to 
ECEF  coordinates.  Units  are  in  Meters/Second. 

1A2.133  ITB-DIS  Linear  Velocity  Vector  Transformation  Methodology 

The  following  paragraphs  describes  the  methodology  in  order  to  translate  the  ITB  Aircraft  linear  velocity 
vector  to  a  DIS  Entity  Linear  Velocity  Vector 

1.  Use  the  rotation  portion  (3x3)  of  the  NEV  relative  to  ECEF  homogeneous  matrix 
developed  previously.  We  will  denote  this  matrix  where  the  subscripts  ij  denote 
the  matrix  row  and  column  respectively: 


■ 

M,; 

M,= 

Ma 

Ma 

Ma 

2.  Multiply  this  matrix  by  the  ITB  supplied  aircraft  linear  velocity  vector  to  obtain  the 
aircraft  linear  velocity  in  ECEF  coordinates  with  units  of  Feet/Second. 

3.  Finally,  multiply  the  results  of  (2)  by  the  Feet  to  Meters  conversion  factor  of  (0.3048). 
This  produces  the  following  result;  answers  are  in  Meters/Second; 

Xlv  =(X1D0TF*M„  +  YIDOTF*M„  +  Z1DOTF*M,3)*.3048 
Ylv  =(X1D0TF*M3,  +  Y1DOTF*Mjj  +  Z1DOTF*Mj3)*.3048 
Zlv  =  (XIDOTF*  M„  +  YIDOTF*  M„  +  ZIDOTF*  M33  )♦ .  3048 


Tl»  following  paragraphs  describes  the  methodology  in  order  to  translate  the  DIS  Entity  linear  velocity 
vectors  into  an  ITB  Aircraft  linear  velocity  vector: 

1.  Use  the  rotation  portion  (3x3)  of  the  NEV  relative  to  ECEF  homogeneous  matrix 
developed  previously.  We  will  denote  this  matrix  Mj^  where  the  subscripts  ij  denote 
the  matrix  row  and  column  respectively: 


■ 

M„- 

M,= 

Ma 

Mj, 

Ma 

.  M„ 

M,3. 
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2.  Multiply  the  inverse  of  diis  matrix  by  the  DIS  suf^lied  entity  linear  velocity  vector  to 
obtain  the  ITB  aircraft  linear  velocity  in  NEV  coordinates  with  units  of 
Meters/Second. 

3.  Finally,  multiply  the  results  of  (2)  by  the  Meters  to  Feet  conversion  factor  of 
(3.2808398).  This  produces  the  following  result;  answers  are  in  Feet/Second: 

X1DOTF  =  (Xlv*M„  +  YLv*Ma  +  Z,.v*M„)*  3.2808398 
Y1DOTF  =  (Xlv*M,i  +  Ylv*M„  +Zi.v*Ma)*3.2808398 
Z1DOTF  =  (Xlv*M,j  +  Ylv*Mb  +  Zi.v*M,3)*3.2808398 

2.4.2.1.4  Linear  Acceleration  Vector 

The  DIS  environment  requires  a  linear  acceleration  vector  definition  for  the  entity  in  questioa  The  next 
few  paragraphs  describe  the  ITB  linear  acceleration  vector,  the  DIS  linear  acceleration  vector  and  the 
metlKxlology  required  to  translate  between  the  two. 

2.4.2.1.4.1  ITB  Aircraft  Linear  Acceieration  Vector 

The  ITB  supplies  the  aircraft  linear  velocity  vector  in  Ft/S^  as  referenced  to  the  ITB  body-fixed 
coordinate  system.  This  vector  is  calculated  in  subroutine  ACCEL  of  program  AIRPLN  if  the  aircraft  is 
airborne  or  in  subroutine  LACCEL  of  program  AIRPLN  if  the  aircraft  is  on  or  near  the  ground.  The 
vector  is  ^ven  the  following  symbols: 

1.  UDOTTF:  Acceleration  of  the  aircraft  in  the  X-Body  direction  with  respect  to  the 
body-fixed  coordinate  system.  Units  are  Ft/S^. 

2.  VDOTTF:  Acceleration  of  the  aircraft  in  the  Y-Body  direction  with  respect  to  the 
body-fixed  coordinate  system.  Units  are  Ft/S^. 

3.  WDOTTF:  Acceleration  of  the  aircraft  in  the  Z-Body  direction  with  respect  to  the 
body-fixed  coordinate  system.  Units  are  Ft/S^. 

2.4  J.1.4..2  DIS  Entity  Linear  Acceleration  Vector 

DIS  requires  the  entity  linear  acceleration  vector  be  in  M/S^  as  referenced  to  the  DIS  entity-fixed 
coordinate  system.  The  following  applies  for  the  DIS  entity  linear  acceleration  veaor. 

1.  X  Linear  Acceleration  (X^^):  Acceleration  of  the  entity  in  the  X  direction  with 
respect  to  the  entity  coordinates.  Units  are  in  M/S^. 

2.  Y  Linear  Acceleration  (Yl^):  Acceleration  of  the  entity  in  the  X  direction  witii 
respect  to  the  entity  coordinates.  Units  are  in  M/S^. 

3.  Z  Linear  Acceleration  Acceleration  of  the  entity  in  the  X  direction  with 

respect  to  the  entity  coordinates.  Units  are  in  M/S^. 

2.42.1AJ  ITB-DIS  Linear  Acceleration  Vector  Transformation  Methodology 

Due  to  the  fact  that  both  the  ITB  and  DIS  linear  acceleration  vectors  are  referenced  to  their  respective 
“body-fixed”  coordinate  systems  and  the  fact  that  both  the  ITB  and  DIS  “body-fixed”  coordinate  systems 
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are  coincident  (the  same),  no  translations  or  rotations  are  necessary.  Only  a  conversion  between  Ft/S^  and 
M/S^  is  required.  Therefore: 

Xi^  =  (0.3048)*UDOTTF  (M/S^) 

Yl^  =  (0.3048)*VDOTTF  (M/S2) 

=  (0.3048)*WDOTTF  (M/S^) 

and 

UDOTTF=Xla  •  (3.2808398)  (Ft/S^) 

VDOTTF=Yla  *  (3.2808398)  (Ft/S^) 

WDOTTF=Zla  *  (3.2808398) 


2.4  J.1,5  Angular  Velocity  Vector 

The  DIS  environment  requires  an  angular  velocity  vector  definition  for  the  entity  in  question  The  next 
few  paragraphs  describe  the  ITB  angular  velocity  vector,  the  DIS  angular  velocity  vector  and  the 
metluxlology  required  to  translate  between  the  two. 

1A21S.\  ITB  Aircraft  Angular  Velocity  Vector 

The  ITB  supplies  the  aircraft  angular  velocity  vector  in  Radians/Second  as  referenced  to  the  body-fixed 
coordinate  system.  This  vector  is  calculated  in  subroutine  INTACC  of  program  AIRH^  if  the  aircraft  is 
airborne  or  in  subroutine  LINTAC  of  program  AIRPLN  if  the  aircraft  is  on  or  near  the  ground.  The 
vector  is  given  the  following  symbols: 

1.  PBODYR:  Angular  velocity  of  the  aircraft  about  the  X-Body  axis  (Roll  Rate)  with 
respea  to  the  body-fixed  coordinate  system.  Qockwise  rotation  is  positive  and  the 
units  are  Radians/^cond. 

2.  QBODYR:  Angular  velocity  of  the  aircraft  about  the  Y-Body  axis  (Pitch  Rate)  with 
respea  to  the  body-fixed  coordinate  system.  Qockwise  rotation  is  positive  and  the 
units  are  Radians/Second. 

3.  RBODYR:  Angular  velocity  of  the  aircraft  about  the  Z-Body  axis  (Yaw  Rate)  with 
respea  to  the  body-fixed  coordinate  system.  Qockwise  rotation  is  positive  and  the 
units  are  Radians/^ond. 

2.4.2.1.S  J  DIS  Entity  Angular  Velodty  Vector 

DIS  requires  the  entity  angular  velocity  veaor  to  be  in  Bams/Millisecond  as  referoiced  to  the  entity-fixed 
coordinate  system.  The  following  applies  for  the  DIS  entity  angular  velocity  vector. 

1.  X  Angular  Velocity  (X^^y)*  Angular  velocity  of  the  entity  about  the  X-Entity  axis 
(Roll  Rate)  with  respect  to  the  entity-fixed  coordinate  system.  Counter-clockwise 
rotation  is  positive  and  the  units  are  Bams/Millisecond. 

2.  Y  Angular  Velocity  (Yav)*  Angular  velocity  of  the  entity  about  the  Y-Entity  axis 
(Pitch  Rate)  with  respect  to  the  entity-fixed  coordinate  system.  Coumer-clockwise 
rotation  is  positive  and  the  units  are  Bams/Millisecond. 
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3.  Z  Angular  Velocity  (Z^y):  Angular  velocity  of  the  entity  about  the  Z-Entity  axis 
(Yaw  Rate)  with  respect  to  the  enuty-fixed  coordinate  system.  Counter-clockwise 
rotation  is  positive  and  the  units  are  Bams/Millisecond. 

2.4JL1.5 J  ITB-DIS  Angular  Velodty  Vector  Transformation  Methodology 

Due  to  the  fact  that  both  the  1TB  and  DIS  angular  acceleration  vectors  are  referenced  to  their  req)ective 
“body-fixed”  coordiiuite  systems  and  the  fact  that  both  the  ITB  and  DIS  “body-fixed”  coordinate  systems 
are  coincident  (the  same),  no  translations  or  rotations  are  necessary.  Chily  a  conversitm  between 
Radians/Second  and  Bams/Millisecond  as  well  as  a  conversion  between  Qockwise  and  Counter- 
Clockwise  is  required.  If  the  Radians/Secoml  to  Bams/Millisecond  conversion  factor  is  given  as  ‘C’,  then 

Xav  =  -(C)*PBODYR  (Bams/Millisecond) 

Yav  =  *(0*QBODYR  (Bams/Millisecond) 

Zav  =  -(O*RB0DYR  (Bams/Millisecond) 

and 

PBODYR=-(1/C)*Xav  (Radians/Second) 

QBODYR=-(1/C)*Yav  (Radians/Second) 

RBODYR=-(1/C)*Zav  (Radians/Second) 

2A2.1j6  Location  Vector 

The  DIS  envirorunent  requires  a  location  vector  definition  for  the  entity  in  question.  The  next  few 
paragraphs  describe  the  ITB  location  vector,  the  DIS  location  vector  and  the  methodology  required  to 
translate  between  the  two. 

2.4.2.1.6.1  ITB  Aircraft  Location  Vector 

The  ITB  supplies  the  aircraft  location  vector  in  Feet  as  referenced  from  the  center  of  the  ITB  inertial 
(NEV)  coordinate  system.  This  vector  is  calculated  in  subroutine  INTVEL  of  program  AIRPLN  and 
given  the  following  symbols: 

1.  XIAIRF:  Location  of  the  aircraft  in  the  X  direction  C'North”)  with  respect  to  the 
NEV  inertial  coordinate  system.  Units  are  Feet. 

2.  Y1  AIRF:  Location  of  the  aircraft  in  the  Y  direction  (“East”)  with  respect  to  the  NEV 
inertial  coordinate  syst^.  Units  are  Feet. 

3.  ZIAIRF:  Location  of  the  aircraft  in  the  Y  direction  (“Down”)  with  respect  to  the 
NEV  inertial  coordinate  system.  Units  arc  Feet. 

2.4.2.1.6.2  DIS  Entity  Location  Vector 

DIS  requires  tire  entity  location  vector  to  be  in  Meters  as  referenced  from  the  center  of  the  ECEF  inertial 
cootdir^  system.  The  following  applies  for  the  DIS  entity  location  vector. 

1.  X  Location  (X£cef)*  Location  of  the  entity  in  the  X  direction  with  respect  to  ECEF 
coordinates.  Units  are  in  Meters. 
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1.  Y  Location  (Y|yTiy)«  Location  of  the  entity  in  the  Y  directi(»i  with  re^)ea  to  ECEF 
coordinates.  Units  are  in  Meters. 

3.  Z  Location  Location  of  the  entity  in  dre  Z  direction  with  req)e(^  to  ECEF 

coordinates.  Units  are  in  Meters. 


2.4J2,1j63  ITB*D1S  Location  Vector  Transformation  Methodology 

The  following  paragn^hs  describes  the  methodology  in  order  to  translate  the  ITB  Aircraft  locatitm  vector 
to  a  DIS  Entity  location  vector 


1.  Use  the  NEV  relative  to  ECEF  homogeneous  matrix  developed  previously.  We  will 
denote  this  matrix  M,y  where  the  subscripts  ij  denote  the  matrix  row  ^  column 
respectively: 


■ 

M,; 

M„ 

M^ 

M„ 

M^ 

2.  Multiply  this  matrix  by  the  ITB  su^qilied  aircraft  location  vector  to  obtain  the  aircraft 
location  in  ECEF  coordinates  with  units  of  Feet; 


XIAIRF 

YIAIRF 

ZIAIRF 

1 

3.  Finally,  multiply  the  results  of  (2)  by  the  Feet  to  Meters  conversion  factor  of  (0.3048). 
This  produces  the  foUovdng  result;  answers  are  in  Meters: 

Xecep  =  (XIAIRF  *  M„  +  YIAIRF*  M„  +  Z1 AIRF  ♦  M„  + 1  *  M,J*.  3048 
Yech.  =  (XIAIRF  *  Mji  +  Y1  AIRF  •  Mjj  +  Z1  AIRF  *  M*,  + 1  *  M^)*.3048 
Zbcb:  =  (XIAIRF  *  M„  +  YIAIRF*  M,j  +  ZIAKF  *  M„  + 1  *  M,«)*.3048 


The  following  paragraphs  describes  the  methodology  in  order  to  translate  the  DIS  Entity  location  vectors 
into  an  ITB  Aircraft  location  vector. 


1.  Use  the  NEV  relative  to  ECEF  homogeneous  matrix  developed  previously.  We  will 
denote  this  matrix  M,y  where  the  subscripts  ij  denote  the  matrix  row  mA  column 
respectively; 


■  M„ 

M„ 

M,; 

Mo 

Mo 

Mo 

M„ 

Mo 

M„ 

Mo 

M« 

M« 

Mo 
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2.  Multiply  the  inverse  (transpose)  of  this  matrix  by  the  DIS  supplied  entity  locatitm 
vector  to  obtain  the  ITB  aircraft  location  in  NEV  coordinates  with  units  of  Meters: 


XIAIRF' 

YIAIRF 

Ybop 

ZIAIRF 

ZgoP 

1 

1 

3.  I^naUy,  multiply  die  results  of  (2)  by  the  Meters  to  Feet  conversion  factor  of 
(3^8(^398).  This  produces  the  following  result;  answers  are  in  Feet: 

XIAIRF  =  (Xbc*  *  Ml,  +  Y^ca.  *  M„  +  *  M„  + 1  *  M.,)  *  3.2808398 

Y1 AIRF  =  (Xbop  *  M„  +  *  M^  +  *  M„  + 1  •  M«)  •  3.2808398 

ZIAERF  =  (Xkbp  *  M„  +  *  Mj,  +  Z^  *  M„  + 1  *  M«)  *  3.2808398 

2.4^1.7  Orientation  Vector 

The  DIS  environment  requires  a  orientation  vector  definition  for  the  entity  in  question.  The  next  few 
paiagrqte  describe  the  113  orientation  vector,  die  DIS  orientation  vector  and  the  methodology  required 
to  translate  between  the  two. 

2.4.J.1.7.1  ITB  Aircraft  Orientation  Vector 

The  ITB  supplies  the  aircraft  orientation  vector  in  Radians  as  referenced  from  the  body-fixed  coordinate 
system.  This  vector  is  calculated  in  subroutine  INTVEL  of  program  AIRPLN  and  given  the  following 
symbols: 


1.  ACPSIR:  Euler  Yaw  angle.  Units  are  Radians. 

2.  THETAR:  Euler  Pitch  angle.  Units  are  Radians. 

3.  ACPHIR:  Euler  Roll  angle.  Units  are  Radians. 

2.4,2.1.7J2  DIS  Entity  Orientation  Vector 

DIS  requires  the  entity  orientation  vector  to  be  in  Bams  as  referenced  with  respect  to  the  entity-fixed 
coordinate  system.  The  following  applies  for  the  DIS  entity  orientation  vector 

1.  PSIdis:  Euler  Yaw  angle.  Units  are  Bams. 

2.  THETAdis:  Euler  Pitch  angle.  Units  are  Bams. 

3.  PHI015:  Euler  Roll  angle.  Units  are  Bams. 

2,4.2.1.73  ITB-DIS  Orientation  Vector  Transformation  Methodology 

Due  to  die  fact  that  both  the  1Tb  and  DIS  Euler  are  refeimiced  to  their  respective  “body-fixed”  coordinate 
systems  and  the  fact  that  both  the  ITB  and  DIS  “body-fixed”  coordinate  systems  are  coincident  (the 
same),  no  translations  or  rotations  are  necessary.  Only  a  conversion  between  Radians  and  Bams  is 
required.  If  the  Radians  to  Bams  conversion  factor  is  given  as  ‘D’,  then 
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PSIms=  (D)*ACPSIR  (Bams) 

THETA0|s=  (D)*THETAR  (Bams) 

PHIdis=  (D)*ACPHIR  (Bams) 

and 

ACPSIRs  (1/D)*PSIdjs  (Radians) 
THETARs  (1/D)*THETAdjs  (Radians) 
ACPHIR=  (l/D)*PHIias  (Radians) 


ZAJldJi  Dead  Reckoning 

The  DIS  environment  requires  that  a  specific  method  of  position/orientation  estimation  (called  Dead 
Reckoning)  be  employed  in  order  to  limit  the  rate  at  which  Entity  State  PDUs  are  issued.  Each  host 
computer  maintains  a  high  fidelity  model  of  itself  (representing  its  actual  position)  and  a  lower  fidelity, 
dead  reckoned  model  of  itself.  Certain  thresholds  are  established  as  criteria  for  determining  if  die  entities 
actual  position/orientation  has  varied  from  its  dead  reckoned  position/orientation.  When  the  entities 
actual  position/orientation  has  varied  form  the  dead  reckoned  position/orienution  by  more  than  the 
threshold,  then  the  entity  issues  an  Entity  State  PDU  to  communicate  to  the  other  host  ccnnputers  its 
actual  positioiL  The  entity  also  uses  the  same  information  communicated  to  other  host  computers  to 
iqidate  its  own  dead  reckoning  modd  of  itself. 

Each  host  computer  also  maintains  a  dead  reckoned  model  of  the  position/orientation  of  entities  that  are 
of  interest  as  specified  by  the  dead  reckoning  model  in  use.  The  dead  reckor^  position/  orientation  of 
the  other  entities  are  used  to  display  their  position/orienution  in  the  host  entities  visual  or  sensor 
displays.  When  the  host  entity  receives  a  new  update  fiom  one  of  tte  entities  it  is  dead  reckoning,  it 
corrects  its  dead  reckoned  modd  and  bases  its  estimations  on  the  most  recent  position/orientation  vdocity 
and  accderation  information. 

The  dead  reckoning  algorithms  required  for  the  DIS-ITB  interface  will  be  those  supplied  in  the  DIS 
Military  Standard  document. 

2.4^2  Entity  Database 

Figure  2.4-2  illustrates  the  Entity  Daubase.  which  provides  input  to  the  PDU  processor.  The  purpose  of 
the  Entity  Daubase  is  to  supply  deuiled  simulation  information  about  entity  types.  The  Entity  Daubase 
will  be  a  text  file  comprising  records  that  include  information  about  each  type  of  entity  that  will  be 
encountered  in  a  scenario.  The  key  to  each  record  will  consist  the  following  fidds  from  an  Entity  Type  in 
an  Entity  Sute  PDU. 

•Entity  kind 
•Country 
•Category 
•  Subcategory 
•Spedfic 


For  example,  the  key  for  an  American  F-15E  aircraft  is  as  follows; 

•  Entity  kind  =  1 

•  Country  =  168 
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•Ctt^nyB  1 

•  Subcategoiy  s  7 

•  Spediic  s  0  (not  q^plicable) 

Tbe  data  in  eadi  record  omsists  of  information  to  support  realistic  iqHcsauatimi  of  the  ouity  in  the  ITB. 
The  ftdlowing  data  will  be  part  of  eadi  Entity  Database  record. 

•  BBN  Display  ED 

•  Relative  size  of  entity,  actual  values  TBD 

•  Dimensions  of  entity,  actual  values  TBD  pending  full  definition  of  collision 
determination  algorithm 

During  ITB  initialization,  the  Entity  Database  will  be  read  into  ITB  random  access  memory  for  efficient 
access  during  simulation.  When  an  Entity  State  PDU  is  received  for  an  entity  that  has  not  yet  been 
encountered,  its  record  will  be  accessed  and  information  placed  in  its  Entity  Data  Structure  record.  There 
should  be  an  Entity  Database  record  for  each  entity  type  in  the  scenario.  There  will  be  provisions  for 
specifying  generic  information  so  that  unknown  entity  types  will  be  mdimentarily  represent^. 

2.4 Use  of  Terrain  and  Cultural  Databases 

Project  2851  has  been  making  raind  progress  in  standardizing  terrain  and  cultural  database  interpretatitm. 
Two  military  standards  have  b^n  produced.  The  first,  called  the  Generic  Transformed  £>ata  Base 
(GTDB)  is  intended  for  release  of  original  infoimatioa  The  second,  called  Standard  Simulator  Data  Base 
(SSDB)  Interchange  Format  (SIF),  is  meant  to  support  the  exchange  of  enhmiced/customized  daubases 
between  sites  and  simulators.  SIF  seems  to  be  becoming  the  de  facto  standard  for  terrain  representation  in 
image  generators.  SIF  uses  ASCII  format,  which  greatly  simplifies  its  interpretation,  and  is  easier  to  use 
(based  on  preliminary  comments)  than  GTDB.  However,  the  SIF  standard  is  being  revised,  with  release 
expected  in  early  1993. 

At  the  Interservice/Industry  Training  Systems  Corrference  (I/TTSC)  in  November,  1992,  there  will  be  an 
interoperability  demonstration  using  DIS.  The  purpose  of  the  demonstration,  which  is  an  initiative  of  the 
Defense  Modeling  and  Simulation  Office  (DMSO),  is  to  encourage  the  adoption  of  DIS  for  tte  network 
protocol  and  SIF  for  the  database  interchange  format.  DMSO  intends  to  seed  the  development  of  a 
technical  suf^rt  infrastructure  in  these  areas.  This  is  being  accomplished  through  the  conversion  of  the 
Hunter-Liggett  database  into  SIF  format  This  database  will  be  provided  to  all  participants  to  convert  into 
their  internal  image  generator  format  for  use  in  the  demonstration.  Use  of  this  datab^  is  being  strongly 
encouraged. 

SEP  capability  for  the  ITB  is  highly  recommended.  SIF  data  would  be  required  for  the  OTW/FLIR 
display,  die  HUD,  and  the  ITB  internal  processing.  Use  of  SDF  data  would  probably  require  modificatkm 
of  the  internal  processing  software  for  the  OTW/FLIR  and  HUD.  These  displays  are  produced  by  BBN. 
BBN  has  been  following  Project  2851  work  and  attending  conferences,  and  should  be  aware  of  the  work 
involved.  SIF  terrain  data  is  gridded  in  a  similar  manrrer  to  what  is  currently  used  by  the  ITB  software.  It 
has  not  been  possiUe  to  determine  die  level  of  effort  required  to  use  SIF  data,  since  the  document  we  used 
did  not  have  the  detailed  formats  or  examples.  Experiences  and  lessons  learned  from  the  I/ITSC 
demonstraricm  participants  could  be  applied  directly  to  niase  II  efforts. 
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ACRONYMS  AND  ABBREVUTIONS 


ADSS 

AFB 

AFTT 

AKA 

ASCn 

BAM 

BBN 

BIU 

CAS 

CDRL 

CNI 

DIS 

DMA 

DMSO 

E 

ECEF 

FUR 

GENASIS 

GPS 

GTDB 

HUD 

Hz 

i/rrsc 

VO 

IBM 

ID 

IEEE 

lESS 

1ST 

rre 

LAN 

MBT 

MSS 

N/A 


Availability  Demonstration  Simulation  Suppoit 
Air  Force  Base 

Air  Force  Institute  of  Technology 
Also  Known  As 

American  Standard  Code  for  Information  Interchange 

Binary  Angular  Measurement 

Bolt  Beranek  and  Newman 

Bus  Interface  Unit 

Qose  Air  Support 

Contract  Data  Requirements  List 

Communication.  Navigation,  and  Identification 

Distributed  Interactive  Simulation 

Direct  Memory  Access 

Defense  Modeling  and  Simulation  Office 

East 

Earth-Centered  Earth-Fixed 
Forward  Looking  Infrared 

Generalized  Avionics  Simulatiori/lntegration  System 

Global  Positioning  System 

Generic  Transformed  Data  Base 

Head’s-Up  Display 

Hertz 

Interservice/Industry  Training  Systems  Conference 
Input/Output 

Irttemational  Business  Machines 
Identifier 

Institute  of  Electrical  and  Electronics  Engineers 

Integrated  Electromagnetic  Simulator  System 

Institute  for  Simulation  and  Training 

Integrated  Test  Bed 

Local  Area  Network 

Multiplex  Bus  Terminal 

Model  Simulation  System 

Not  Applicable 
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NEV 

Noith-East-Vertical 

OSl 

Open  System  Interconnection 

OTW 

Out-the- Window 

PC 

Personal  Computer 

PDU 

Protocol  Dau  Unit 

RF 

Radio  Frequency 

SBIR 

Small  Business  Innovative  Research 

SIF 

SSDB  Interchange  Format 

SIMNET 

Simulator  Network 

SSDB 

Standard  Simulator  Data  Base 

TBD 

To  Be  Defined 

UDP/IP 

User  Datagram  Protocol/lnten^t  Protocol 

UTC 

Universal  Coordinated  Time 

WGS-1984 

World  Geodetic  System  1984  Survey 

WL 

Wright  Laboratory 
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Interservioe/Industry  Training  Systems  Conference  1990:  SIMNET  Fighter  Aircraft  ApplicatiMi”. 
Armstrong  Laboratory  Aircrew  Training  Research  Division,  Document  No.  AL-TR- 1992-0020, 
March  1992. 

“BBN  GTIOO  CIG  to  Simulation  Host  Interface  Manual,”  BBN  Systems  and  Tet^olo^es,  Document 
No.  8912,  July  1990. 

“Computer  Program  IDevelopment  Specification  for  the  Models  Simulation  System  (MSS)  (STEOOOl), 
Part  n.”  WL/AAAS-2.  Document  No.  SSTEl  1 101, 18  July  1990. 

“Computer  Program  Development  Specification  for  the  Models  Simulation  System  (MSS),  Part  I,” 
WL/AAAS-2.  Document  No.  SSTEl  1 101, 7  March  1989. 

“GTIOO  Interface  and  Applications  Development,”  BBN  Systems  and  Technologies,  undated. 

“Interface  Control  Document  For  Generic  Trainer/Netwoik  Interface  Unit,”  LORAL  Defense  Systems 
Akron,  April  1992  (Preliminary). 

“Military  Standard,  Standard  Simulator  Data  Base  (SSDB)  Interchange  Format  (SIF)  for  Hi^  Detail 
Input/Output  (SDF/HDI)  and  Distributed  Processing  (SIF/DP),"  AMSC/NA,  December  1990  (Draft). 

“Network  Interface  Unit  (NIU)  Detailed  Design  Specification,”  BBN  Systems  and  Technologies,  Report 
No.  7622,  June  1991. 

“PAVE  PILLAR  In-House  Technical  Report  Volume  I  -  Demonstration  1  and  lA,”  WL/AAAS-2,  July 
1990. 

“Protocol  Data  Units  for  Entity  Information  and  Entity  Interaction  in  a  Distributed  Interactive 
Simulation,”  Institute  for  Simulation  and  Training,  30  October  1991. 

“Rationale  Document,  Entity  Information  and  Entity  Interaction  in  a  Distributed  Interactive  Simulation,” 
Institute  for  Simulation  and  Training,  January  1992. 

“Segment  Specification  for  the  Real-Time  Support  System  (RSS)  (STE0(X)1),’  WL/AAAS-2,  Document 
No.  SSTEIOIOI,  28  July  1990. 

“Simulator  Networking  Phase  I  Technical  and  Management  Woric  Plan,”  Amherst  Systems  Incorporated, 
Document  No.  611-9420001  rev.  A,  22  May  1992. 

“Simulator  Networking  Phase  I,  Contractor’s  Progress,  Status  and  Management  Plan,  February  1,  1992 
Through  April  30,  1992,”  Amherst  Systems  Incorporated,  Document  No.  611-9160001,  29  May 
1992. 

“Summary  of  SIMNET  6.6  Implementotion  and  Extensions  for  TRUE,”  LORAL  Eiefense  Systems- 
Akron,  14  April  1992  (Draft). 
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